Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You’re better off using Exceptions

eiriktsarpalis.wordpress.com

Post reply on HN
Print view View original

141–150 of 242 posts

Re: You’re better off using Exceptions

#141

Post by munificent »

baby wrote: post #44
ravenstine wrote: post #14

My problem with exceptions isn't so much exceptions themselves but the way they're used. The way I see it, exceptions should only be used for things that are irreconcilable, which most of the time is interpreter errors(e.g. undefined is not a function). In other words, I don't think it's that common that custom exceptions are needed outside of assertions to prevent the developer from doing something stupid. If you ar…

Actually, I’d argue that exception (that are caught) should only be used for recoverable errors. If you can’t recover, then you should crash.

The great thing about exceptions is that they implement both of these behaviors with a single mechanism.

For recoverable errors, you catch.

For unrecoverable ones, you don't. The exception throwing mechanism unwinds the entire stack and crashes the app with a helpful stack trace.

Re: You’re better off using Exceptions

#142

Post by dana321 »

gnulinux wrote: post #50
dana321 wrote: post #38

What's exception handling actually doing internally? Genuinely interested and i need to know. Must be some kind of "goto catch block" internally when you throw an error. It has to stop the execution and jump somewhere, but that somewhere is set in the code where it catches the error. If you're calling a function then that function throws an error, it has to prematurely exit to somewhere so there must be a stack of th…

For gcc/clang C++, internally, it will unwind the stack until it finds a handler. This way it doesn't have to do anything at the moment of setting a handler (i.e. "try" in the underlying code), as a trade-off it's relatively expensive to throw an exception. But note that C++ standard does not specify this, so it's fair game for compiler to do anything. E.g. it can use long jumps, or just dispatch different functions…

Thanks for that, nice to know!

Re: You’re better off using Exceptions

#143

Post by _ZeD_ »

mrec wrote: post #132
dahfizz wrote: post #119

Earlier quoted context omitted.

The usefulness of exceptions in the cases you present is to force the developer to handle the cases where things go wrong, such as no records are found. There are more clever ways to do this nowadays with monadic Result types, but the core idea of forcing a developer to handle error conditions is useful in API design.

Isn't that "forcing a developer to handle error conditions" only true of Java-style checked exceptions, though? I'm not aware of any non-JVM languages taking that route, even the very Java-clone-y C#, and thought it was widely believed to have been a mistake.

Still some people like me think that checked exception are the damn right way to express the possible outcome of a function. Every time I need to work with C# / python I need to play "catch" to keep track of all the possible exceptions that could be thrown at any function call...

Re: You’re better off using Exceptions

#144

Post by dllthomas »

cjfd wrote: post #134
ravenstine wrote: post #87

Earlier quoted context omitted.

> It's not a normal thing for code that needs that record that wasn't found. No offense, but I don't know where that idea comes from. Systems are checking for records all the time in ways where the absence of data doesn't necessitate throwing an exception. For instance, a page, user, or piece of media on a website may have existed at one point but was since deleted, but still has a permalink floating around the net.…

The code example is not convincing at all. Obviously a single if is much cleaner than a single try/catch block but that is not the comparison. The if needs to be replicated N times for every N things that could fail and that are calling each other in a potentially deep call hierarchy. The try/catch block only needs to occur once at a level that is above all of the N things that might fail.

In my experience, on the web there are two different kinds of things we might be fetching.

Some things are essential to the page we are rendering, and if they are missing we should 404.

Some things are ancillary, and if they are missing we should render a stub in their place. E.g., saying that a comment is from "deleted user".

Exceptions are a good fit for the former, where we want to unify every failure. They are a poor choice for the other case, where we want to treat each failure special.

Which case a given fetch represents is a choice that should be driven by the fetcher.

Re: You’re better off using Exceptions

#145

Post by kibwen »

detaro wrote: post #133
aikah wrote: post #130

Earlier quoted context omitted.

> Nulls are also called the billion-dollar mistake (and that was decades ago; it's much more than that now). Both nulls and exceptions are ways of trying to make the main line of processing clear, while handling other lines in structured ways. At the same time before NULL, devs used to use "guard values", so NULL is really just a convenience. for instance, just to illustrate what I'm saying: let NULL = {} /* should e…

What "functional programming features" does one need for useful optional types?

Putting aside the "functional" bit, for a language to allow user-defined (i.e. not hardcoded into the language itself (which may not necessarily be a bad thing, but that's beside the point here)) optional types, you'd want the ability to say "this variable is either _this_ XOR _this_" (a.k.a. tagged unions/sum types/what Rust calls "enums"), and then in a statically-typed language you'd additionally want generics.

Re: You’re better off using Exceptions

#146

Post by trumpeta »

Here's my problem with exceptions:

(I'm going to treat checked exceptions same as unchecked, because you don't _have to_ use checked or they can be trivially broken by using the Exception superclass)

At the beginning you often take shortcuts and ignore error handling in order to get the happy path to work. Once it is working, it is very easy to overlook some exceptions that should be handled, leading to unexpected runtime errors.

Using the Result monad (say in Rust), you can easily just add .unwrap() after any call that produces a Result to get the happy path working. After you're done with that, its easy to find all the places you took shortcuts and fix them.

To me, the ergonomics of a language is exactly this gap between how concise the "take all the shortcuts" code is and how easy it is to transform into production code where all the possible error states are properly accounted for.

Re: You’re better off using Exceptions

#147

Post by majewsky »

_ZeD_ wrote: post #140
clon wrote: post #123

Earlier quoted context omitted.

> Well, in real code you are likely bubbling up an error in some way for your 404 Not Found and 500 Internal Error handlers to kick in. Which is essentially GOTO 404 A horrible idea that I see often in clever frameworks disobeying encapsulation and reasonable control flow in favour of magic

That is a wonderful idea. You don't need to deal with 404, 500 or other stuff, you just write for the "happy path". The framework deals with the rest.

Then you fill in a complex form with 6 object references, and the framework just spits out "NOT FOUND", which means "have fun figuring out which one is the missing object".

Re: You’re better off using Exceptions

#148

Post by shadowgovt »

wizzwizz4 wrote: post #101
shepmaster wrote: post #56

Earlier quoted context omitted.

> If Rust devs took an everyday English word and gave it a different meaning Perhaps, but if we had come up with a new word, you or someone else would complain that we had done that instead of using a word that people already "understood". :-) English is a language full of elision, and there's nothing inherently wrong with using one word for closely related meanings. When being precise, Rust uses the term "memory uns…

We call it panicking because there's no assumption that you're always able to catch panics. Panicking is an AAAH EVERYTHING WENT WRONG kind of thing, which might trigger an immediate abort if the program is compiled in super-ultra-speedy-make-debugging-really-hard mode; if your code panics, it's always the programmer's fault. The language provides a way of kinda-sorta recovering from an everything-goes-wrong situatio…

All of that having been said...

If you're talking about Rust, I can't comment directly because I haven't used Rust, but I've totally used Go's panic / recover to implement "return" and "break loop" in a language interpreter.

I should really rewrite that thing to do something more sane like bundle up a continuation state to return to, but I was feeling lazy. ;)

Re: You’re better off using Exceptions

#149

Post by interlocutor »

mrec wrote: post #132
dahfizz wrote: post #119

Earlier quoted context omitted.

The usefulness of exceptions in the cases you present is to force the developer to handle the cases where things go wrong, such as no records are found. There are more clever ways to do this nowadays with monadic Result types, but the core idea of forcing a developer to handle error conditions is useful in API design.

Isn't that "forcing a developer to handle error conditions" only true of Java-style checked exceptions, though? I'm not aware of any non-JVM languages taking that route, even the very Java-clone-y C#, and thought it was widely believed to have been a mistake.

Unchecked exceptions are a disaster. In C# when you call a method you have no idea what exceptions can be thrown by the called method unless you inspect the called method and all the methods called by it. The called method can be modified at any time and a new exception can be thrown and your code will compile just fine. This is bad because the new exception may be a recoverable condition and instead of recovering your program will crash. This is why exceptions that can be thrown by a method should be considered part of the signature of the method and you should get a compile-time error (as opposed to a runtime crash) if the method throws a new exception that wasn't there when you originally wrote the code.

Re: You’re better off using Exceptions

#150

Post by dnautics »

iainmerrick wrote: post #107
Seenso wrote: post #62

Earlier quoted context omitted.

> A record not being found is a normal thing! It's not a normal thing for code that needs that record that wasn't found. > They literally tell you nothing and there's no way to solve them without catching/rescuing them. A null value, a plain "error" object, or an error argument in a callback would have been sufficient. If I need an exception to be raised for this kind of thing, I'll do it myself. They tell you lots:…

>> A record not being found is a normal thing! > It's not a normal thing for code that needs that record that wasn't found. This is something of a religious dispute and there are arguments both ways. But I think it’s important to note that an exception is vastly more expensive than a simple function call or return value. So I’d say you need a really good reason to use exceptions. I agree with the GP that in general,…

I don't see what the problem is. The API should expose two methods: `fetch()` which returns, say, nil if there's no result (or an error monad or error tuple, depending on your language), and say `fetch!()` (or `fetch_throws()` if your language doesn't support exclamation points) which raises an exception if there isn't a result. The programmer gets to choose, on a case-by-case basis.
Post reply on HN