3 ms·

I'd argue that Exceptions are good, because they attempt to illustrate all the ways code can go wrong and because you typically need to be at least aware that y

I'd argue that Exceptions are good, because they attempt to illustrate all the ways code can go wrong and because you typically need to be at least aware that you're ignoring them. However, i'd argue for allowing no unchecked exceptions at all that can be thrown at runtime and instead forcing developers to handle every fail state, that can be encountered in the code that they call. If a method that you call can fail in 60 different ways, you should at least handle the 20 of them that you understand in their own ways and the rest in a blanket statement. All of that should be checked at compile-time, of course. Java, .NET and most other ecosystems (both languages and frameworks) don't really seem to want to bother with that, though.

heavenlyblue 6y ago
Is there a language that has optional checked exceptions? Basically if I define a checked exception function then I am expected to check all exceptions that will be thrown?
- MrBuddyCasino 6y ago
  In Java there is Exception (checked) and RuntimeException (unchecked). Depending on which base class you use, the compiler will force you to handle them or not.
MrBuddyCasino 6y ago
One of the problems with exceptions is that they bubble up the call stack, and then you've got layering violations: higher level modules should never depend on lower level modules. The "checked exceptions were a failure" meme goes towards this direction, it results either in nasty boilerplate because you've got to handle and re-wrap the implementation-specific exception in something more general to avoid leaking things that should have been hidden (like Hibernate does), or unsound error handling. Maybe the solution to that is 1. Only allow checked exceptions, and force error handling. 2. Only have 2-3 exception types, not user-extendable: Retryable, Unrecoverable, and Error (for non-user code errors like OOM). OTOH, how to distinguish between different exceptions thrown by the same method, and how to add additional error information (like status_code) would become a problem. Javascript doesn't seem to care tho? A Result type à la Rust solves most of that: you might still have to wrap lower layers, but at least the noise & syntax is much more sane (never thought I'd say that about Rust!).
- girvo 6y ago
  JavaScripts Error type is so loosey-goosey that even TypeScript doesn’t try to work anything out about it. e: any; parse it yourself in your catch haha

heavenlyblue 6y ago

Is there a language that has optional checked exceptions? Basically if I define a checked exception function then I am expected to check all exceptions that will be thrown?

MrBuddyCasino 6y ago
In Java there is Exception (checked) and RuntimeException (unchecked). Depending on which base class you use, the compiler will force you to handle them or not.

MrBuddyCasino 6y ago

One of the problems with exceptions is that they bubble up the call stack, and then you've got layering violations: higher level modules should never depend on lower level modules. The "checked exceptions were a failure" meme goes towards this direction, it results either in nasty boilerplate because you've got to handle and re-wrap the implementation-specific exception in something more general to avoid leaking things that should have been hidden (like Hibernate does), or unsound error handling. Maybe the solution to that is 1. Only allow checked exceptions, and force error handling. 2. Only have 2-3 exception types, not user-extendable: Retryable, Unrecoverable, and Error (for non-user code errors like OOM). OTOH, how to distinguish between different exceptions thrown by the same method, and how to add additional error information (like status_code) would become a problem. Javascript doesn't seem to care tho? A Result type à la Rust solves most of that: you might still have to wrap lower layers, but at least the noise & syntax is much more sane (never thought I'd say that about Rust!).

girvo 6y ago
JavaScripts Error type is so loosey-goosey that even TypeScript doesn’t try to work anything out about it. e: any; parse it yourself in your catch haha