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

Away from Exceptions: Errors as Values

humanlytyped.hashnode.dev

Post reply on HN
Print view View original

31–40 of 145 posts

Re: Away from Exceptions: Errors as Values

#31

Post by zvrba »

> Some errors are unexpected and should stop the program; you want to use exceptions for those.

Precisely the opposite: exceptions are a fail-fast mechanism that gives you an alternative to terminating the program.

Now, as slx26 mentioned, it's only half of the story. Most APIs (including .NET) document exceptions badly, they're not discoverable, and if you try to use them to _recover_ from a condition, you're in for a world of pain. The workflow is usually: attach the debugger, try to make the exceptional condition happen, inspect relevant info in the debugger and write the catch block.

I wish that programming languages supported some contract-like mechanism of declaring: "This method can throw only X, Y and Z". If the method throws anything else, a system-defined "UnexpectedException" would be thrown, encapsulating the invalid one. C++ used this model once upon a time, but they went away from it due to runtime costs and it being little-used. (Also, it terminated the program instead of rewrapping the exception.)

Exceptions are first-class values, but few programmers treat them as such, probably because the programming language allows them to do so. So we should start by fixing PLs.

Re: Away from Exceptions: Errors as Values

#33

Post by Joker_vD »

cube00 wrote: post #25
xg15 wrote: post #19

No, I don't want to wrap every single statement of my program in its own if-block, thank you very much.

This was bread and butter error handling in COM, everything old is new again!

Yep, all hail the mighty

    #define CHECK(com_expr) hr = (com_expr); if (FAILED(hr)) { return hr; }
Ah, the memories... glad I don't have to touch it ever again. "And a million other things that, basically, only Don Box ever understood, and even Don Box can’t bear to look at them any more".

Re: Away from Exceptions: Errors as Values

#34

Post by zvrba »

cletus wrote: post #30

I'm firmly in the camp that believes that exceptions are a false economy. The post links to an "Exception Smells" post that doesn't mention one of my pet peeves: exceptions as control flow. For example, Java's parseInt [1] throws a NumberFormatException if the string can't be parsed. IMHO this is terrible design. As a side note, checked exceptions are terrible design. I wrote C++ with Google's C++ dialect where excep…

> For example, Java's parseInt [1] throws a NumberFormatException if the string can't be parsed. IMHO this is terrible design.

It's unergonomical design, but it's the _correct_ design: the method is declared to return an int, and it can't fulfill its promise: throwing an exception is the right thing to do.

Re: Away from Exceptions: Errors as Values

#35

Post by Joker_vD »

zvrba wrote: post #31

> Some errors are unexpected and should stop the program; you want to use exceptions for those. Precisely the opposite: exceptions are a fail-fast mechanism that gives you an alternative to terminating the program. Now, as slx26 mentioned, it's only half of the story. Most APIs (including .NET) document exceptions badly, they're not discoverable, and if you try to use them to _recover_ from a condition, you're in for…

May I interest you in looking at Java? It has some interesting lessons wrt your proposition.

Re: Away from Exceptions: Errors as Values

#36

Post by p2t2p »

zvrba wrote: post #31

> Some errors are unexpected and should stop the program; you want to use exceptions for those. Precisely the opposite: exceptions are a fail-fast mechanism that gives you an alternative to terminating the program. Now, as slx26 mentioned, it's only half of the story. Most APIs (including .NET) document exceptions badly, they're not discoverable, and if you try to use them to _recover_ from a condition, you're in for…

> I wish that programming languages supported some contract-like mechanism of declaring: "This method can throw only X, Y and Z". If the method throws anything else, a system-defined "UnexpectedException" would be thrown, encapsulating the invalid one

Boy, do I have some news for you... Like about 25 years old news. Did you ever try java?

Re: Away from Exceptions: Errors as Values

#37

Post by 0xFEE1DEAD »

xg15 wrote: post #19

No, I don't want to wrap every single statement of my program in its own if-block, thank you very much.

It's a trade I'm willing to take for simplifying reasoning about non-happy-paths. Try catch is great in theory but it's super easy to shoot yourself in the foot with in bigger projects, either because it's non exhaustive or someone took the easy way out and made a catch which isn't fine grained anough.

Re: Away from Exceptions: Errors as Values

#38

Post by Joker_vD »

tialaramex wrote: post #26
masklinn wrote: post #14

Earlier quoted context omitted.

> Personally, i really like having multiple return values, since being able to give a function multiple inputs but only being able to return a single thing always felt weird - if your require any metadata in a language like Java, then you'd have to come up with wrapper objects and so on. MRV is nice and useful, and “error as value” languages usually have ways to return multiple values (usually in the form of tuple),…

Does a panic count as "handling" the error? I actually agree with Rust's choice here. You, the programmer, know whether some particular error is something you can cope with or not and it's appropriate to panic in the latter case. Where you draw the line is up to you, in a ten line demo chances are "the file doesn't exist" is a panic, in your operating system kernel maybe even "the RAM module with that data in it phys…

> Does a panic count as "handling" the error?

> You, the programmer, know whether some particular error is something you can cope with or not and it's appropriate to panic in the latter case.

Please don't. I've seen enough libraries whose authors had exactly this mindset; I do not enjoy when some fifth-party dependency thrice-removed, upon encountering an unexpected circumstance, decides that it can't bear to live in this cruel world any more and calls "abort()", killing the entire process: which happens to be a server process, running multiple requests in parallel for which a failure to serve any single request for any reason whatsoever does not warrant aborting all other request.

Re: Away from Exceptions: Errors as Values

#39

Post by zvrba »

p2t2p wrote: post #36
zvrba wrote: post #31

> Some errors are unexpected and should stop the program; you want to use exceptions for those. Precisely the opposite: exceptions are a fail-fast mechanism that gives you an alternative to terminating the program. Now, as slx26 mentioned, it's only half of the story. Most APIs (including .NET) document exceptions badly, they're not discoverable, and if you try to use them to _recover_ from a condition, you're in for…

> I wish that programming languages supported some contract-like mechanism of declaring: "This method can throw only X, Y and Z". If the method throws anything else, a system-defined "UnexpectedException" would be thrown, encapsulating the invalid one Boy, do I have some news for you... Like about 25 years old news. Did you ever try java?

Yes. What I'm thinking of are _not_ checked exceptions, at least not at compile-time.

Re: Away from Exceptions: Errors as Values

#40

Post by dthul »

zvrba wrote: post #34
cletus wrote: post #30

I'm firmly in the camp that believes that exceptions are a false economy. The post links to an "Exception Smells" post that doesn't mention one of my pet peeves: exceptions as control flow. For example, Java's parseInt [1] throws a NumberFormatException if the string can't be parsed. IMHO this is terrible design. As a side note, checked exceptions are terrible design. I wrote C++ with Google's C++ dialect where excep…

> For example, Java's parseInt [1] throws a NumberFormatException if the string can't be parsed. IMHO this is terrible design. It's unergonomical design, but it's the _correct_ design: the method is declared to return an int, and it can't fulfill its promise: throwing an exception is the right thing to do.

It's the correct design only if we assume that the design space didn't allow for a different return type. Kotlin for example offers toIntOrNull (https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.text/to-...) as an alternative.
Post reply on HN