3 ms·

> What's the reason behind their prevalence in almost every language? More often than not it's not the caller that is responsible for handling errors/exception

by troupo 2y ago

> What's the reason behind their prevalence in almost every language? More often than not it's not the caller that is responsible for handling errors/exceptions. When you force the caller to take care of every single error, you end up with unreadable boilerplate code which hides the actual logic. There's a reason why Rust ended up with the `?` syntax sugar. On top of that exceptions will occur. You can't pretend they won't and kill the app if they do. Again, even Rust and Go ended up adding handlers for their brain-dead panics. Exceptions (when wielded correctly) end up simplifying your program. You develop for the happy path (mostly), and let code at the higher level of hierarchy make decisions about unhappy paths. That's how you get Erlang's supervision trees (https://erlang.org/documentation/doc-4.9.1/doc/design_principles/sup_princ.html https://erlang.org/documentation/doc-4.9.1/doc/design_princi...)

eikenberry 2y ago
IMO the problem with tools that are great "when used correctly" is that if they don't force that "correctly" part or the feature works in such a way that people just fall into correctly due to path-of-least-resistance, then people don't use it correctly. This, again IMO, is why people have problems with Exceptions. It is that they don't have these qualities and they are almost universally used incorrectly... thus the new languages have eschewed them much like they eschewed heavy handed OO abstractions. They were tried and found to be lacking for their intended purpose and alternatives are being tried.
- MBCook 2y ago
  Right, that’s the Java issue. It becomes very easy to just add “throws Exception“ all over the place to silence warnings when things start to get tricky. Because Swift forces the keyword ‘try’ (or a variant) before calling code that may throw it ends up being a lot of work to try to avoid the issue just by making everything throw. It’s much easier to do the correct thing and just handle the error in a smart place.
- behnamoh 2y ago
  I think this also applies to dynamic typing. Nowadays we see a shift back to typed languages because most people who use dynamically typed languages don't bother add even type hints (which is awful in a JS/Python codebase).
MBCook 2y ago
I’m not familiar with Rust, but Swift has three options and it sounds like it may be similar. In Swift code that throws when called must have “try” in front of it, making it really obvious where that’s going on. Your three options: try - calls the code and either returns the like normal or an error that you’re forced to handle in a catch. try? - calls the code and returns the value or nil (null value) if an error is thrown. try! - calls the code and returns the value. If the function throws an error your app panics. It’s quite nice. You can choose to handle the error when you need to. If you don’t really care about the specifics of the error and just want to treat any kind as a failure try? cleans up your code. And try! lets you avoid writing boilerplate when you know it’s impossible for the error to be thrown but the compiler can’t deduce that from the source alone.

by troupo 2y ago

eikenberry 2y ago

IMO the problem with tools that are great "when used correctly" is that if they don't force that "correctly" part or the feature works in such a way that people just fall into correctly due to path-of-least-resistance, then people don't use it correctly. This, again IMO, is why people have problems with Exceptions. It is that they don't have these qualities and they are almost universally used incorrectly... thus the new languages have eschewed them much like they eschewed heavy handed OO abstractions. They were tried and found to be lacking for their intended purpose and alternatives are being tried.

MBCook 2y ago
Right, that’s the Java issue. It becomes very easy to just add “throws Exception“ all over the place to silence warnings when things start to get tricky. Because Swift forces the keyword ‘try’ (or a variant) before calling code that may throw it ends up being a lot of work to try to avoid the issue just by making everything throw. It’s much easier to do the correct thing and just handle the error in a smart place.
behnamoh 2y ago
I think this also applies to dynamic typing. Nowadays we see a shift back to typed languages because most people who use dynamically typed languages don't bother add even type hints (which is awful in a JS/Python codebase).

MBCook 2y ago

I’m not familiar with Rust, but Swift has three options and it sounds like it may be similar. In Swift code that throws when called must have “try” in front of it, making it really obvious where that’s going on. Your three options: try - calls the code and either returns the like normal or an error that you’re forced to handle in a catch. try? - calls the code and returns the value or nil (null value) if an error is thrown. try! - calls the code and returns the value. If the function throws an error your app panics. It’s quite nice. You can choose to handle the error when you need to. If you don’t really care about the specifics of the error and just want to treat any kind as a failure try? cleans up your code. And try! lets you avoid writing boilerplate when you know it’s impossible for the error to be thrown but the compiler can’t deduce that from the source alone.