Exactly, C++ exceptions are horrible, you never know what throws what. Java made C++ exceptions better by making them explicit, so you always know what throws. Then Kotlin came and made everything a unusable mess (don't get me wrong, I love Kotlin, just hate that it doesn't have explicit exceptions). I honestly think the best error handling strategy is employed by Zig, then Rust. they're very explicit while not getti…
I think the way Go does error handling is the best compromise.
It's a successful compromise, but probably not the best. It has a huge amount of little issues that simply aren't there with FP error handling.
Reading through the comments, I realize this may be a minority view - but I like coding for the happy path and letting exceptional states crash. I find languages like go a bit harder to parse quickly because I always have to "unwrap" the happy path from all of the mixed in error handling. I'm sure I'd get used to it eventually, but I like that unchecked exceptions in Java are now an option!
In practice there is a lot of paths that you don't want to "crash" on, but try the next thing etc.
The Trouble with Checked Exceptions A Conversation with Anders Hejlsberg, Part II https://www.artima.com/articles/the-trouble-with-checked-exc...
This is an insightful interview, thank you for the link. I'm well read up on the topic, but this interview was still great and is a good perspective on the checked/unchecked debate.
The fact that Java has introduced UncheckedIOException, in my opinion, shows how some people in the Java community have come to believe that checked exceptions were a mistake (understanding that lambda forced the issue). There's probably not too much to be easily done at this point, but consideration for changing checked exceptions in the JDK to extend RuntimeException sure would be interesting.
Allowing unchecked exceptions in languages without explicit error handling or the return of error values is a mistake IMO! Makes it impossible to call a function safely
The entire community disagrees with you[1] >Makes it impossible to call a function safely ?? catch(Exception e) anyone? [1] https://literatejava.com/exceptions/checked-exceptions-javas...
A lot of people, probably. But definitely not the entire community [0].
The Trouble with Checked Exceptions A Conversation with Anders Hejlsberg, Part II https://www.artima.com/articles/the-trouble-with-checked-exc...
This is an insightful interview, thank you for the link. I'm well read up on the topic, but this interview was still great and is a good perspective on the checked/unchecked debate. The fact that Java has introduced UncheckedIOException, in my opinion, shows how some people in the Java community have come to believe that checked exceptions were a mistake (understanding that lambda forced the issue). There's probably…
I think this project shows how trivial it is to convert checked exception errors to compiler warnings.
I don't want to remove all checked exceptions in random code, btw. Even though they're not common, it can be bad if they're unhandled in some cases. How can I know beforehand?
I'd like something to soften some of them, probably in a configurable way, in some builtin interfaces btw. E.g. many IOExceptions should really be unchecked.
Allowing unchecked exceptions in languages without explicit error handling or the return of error values is a mistake IMO! Makes it impossible to call a function safely
Java just needs one small change to fix exceptions.
Instead of the exception type being checked or unchecked, the throw should specify checked or unchecked.
So for example the first time the exception happens it can throw a checked exception for the caller to deal with.
If the caller doesn't deal with it it can simply throw its way all the way to the top without every single function needing to declare they handle it.
The problem with that is you lose all ability to understand or control what a given endpoint will return in any given situation > I have no specific error handling for the given problem then pass it on and decide what to do with it at the system boundary in the db: fun getUser(uuid: UUID) : Either middle layers: pass around the either, you can map, flatmap etc on it to chain it with other computations there then in t…
> The problem with that is you lose all ability to understand or control what a given endpoint will return in any given situation Why? In the simplest (but pretty common) case it's: - successful response - generic error message > then pass it on and decide what to do with it at the system boundary Yes, but if in 99% of cases I only pass it on, it's just visual noise. Noise you become blind to, and it loses meaning. >…
You're describing the problems with exception, not using Either... When using Either, you never fold on those errors individually... Anyway, it's clear we're not going to agree, and you win, since so far the industry is still stubbornly clinging to exceptions, despite them being a failed feature in every language they're in.