I’d rather have exceptions thrown for a simple reason: errors as values make it too easy to ignore them. You have to explicitly check for errors and take a different course of action rather than your program do it for you.
If I’m parsing a JSON and there’s a syntax error, I definitely DO NOT want my program to keep running and risk entering an undefined state because a function somewhere is not checking the error value. An exception forces the consumer of a function to handle it, or have the program fail. The point the article makes about “not being able to tell where the error came from” is bogus since there’s a stack trace.
IME the default behavior of a program when facing an unhandled error should be to stop execution. There are a million things that could go wrong. We can’t cover them all and we shouldn’t expect consumers to check for errors on every line when they might not even be able to handle them: that’s where bubbling up errors really comes in handy. And making it happen when they’re just values require all intermediate functions to check for them.
Yeah, at $DAYJOB, we switched (regrettably) from Scala to Kotlin and wanted to continue using the errors-as-value style, which I was the biggest proponent of. However, there not being a way to make the Kotlin compiler shout at you, if you implicitly ignore a return value, really made me question that choice.
It means that if you refactor a function to now be able to fail, then you have to go to all usages and make sure you continue the bubbling.
With exceptions, you should also do that, to potentially introduce try-catches, but if you don’t, then it will at least crash very visibly.
If the compiler does shout at you, like in Scala and Rust, then I think, that’s a better pattern.
Especially when you tell the compiler to treat unhandled error types as error instead of warning.
If you wrote the type signature of
get_userastuple[User, None] | tuple[None, Exception], the assertion would not be necessary and the type checker wouldn’t complain.They forgot the Erlang approach: throw exceptions but never catch them. If you are throwing an exception either your code is wrong or your system is bad. In either case, you should crash violently and let another instance handle the retry.
Do they then they extensively use algebraic data types like rusts Option?
I’ve actually been experimenting with this on and off for about a year now. My team and I also came to the conclusion that unions were the best approach but we hadn’t considered using
match. Might give that a shot if any type systems start supporting it betterThe words errors, go and usefull do not match in my brain.
If there is a way not to implement error handling, it would clearly be go’s implemenation.
no, there’s no better error handling than writing
if err != nil { return err }after every line of code, this is clearly the superior way/s
Rusty python
If only python had a
throwskeyword like in Java. They got that right at least.raiseandraise…from?I think they meant the registration of what Exceptions a function can possibly throw.
ah yes - that’s useful
I disagree, I hate that keyword. Exceptions should be… exceptional, and regular errors should be data. I only want to see exception blocks at top levels for logging and whatnot, everything else should be destructured monads in a match block or similar.
Forgetting a function can throw exceptions is an honest mistake, ignoring errors when you’ve destructured a return value to get the data is a choice. The former is hard to catch, the latter is plainly obvious in a code review.
I don’t really see the point of this approach. The whole bane of programming in low level languages like C is that you had to write one line of code, then 10 lines of error management for that line. Repeat until 500 lines, potentially with gotos in order to rollback previously successful operations. The result was that C was mostly error handling of function calls, and the ways to return such errors were hackish. Add reentrancy and multithreading requirements and it became a mess.
The idea of exception throwing is to forget all of this and have a separate channel where exceptions conditions flow, so the code is mean and lean and just does things, and when something goes wrong it throws a fit. If someone understands and manages that fit, great, there will be a specific handler for that, otherwise it won’t.
So I don’t really see a big case for going back to the old days of errors as values, because it really, really sucked.
I disagree. I’ve had to debug messes where errors are only really caught at the top level, and often there’s something that programmer could’ve done to properly handle it but didn’t because it wasn’t clear that the function they called could produce an error.
And that’s where Go and Rust do a fantastic job imo. Since you’re forced to acknowledge errors, you give the programmer the opportunity to handle them and take corrective action. I like the Rust syntax a bit more because it’s easy to return errors without messing with logic flow, so you can handle all errors at the calling function easily if that’s better for logic flow.
The best solution for Python, imo, is a mix. Here are some things I’d love to see that are related here:
- optional chaining -
x = y?.z ?? DEFAULTinstead ofx = y.z if y else DEFAULT(esp for nontrivial nesting) - monads - return can be an error or value, and you need to determine which before unpacking it; could work with optional chaining as well (would return from the function with the error, otherwise continue with the data), or require destructuring (e.g. with match blocks); similar to try/except, but there’s no assumption of success
Some libraries used to do it this way, such as Marshmallow (used a monad pattern).
Sometimes its cleaner and more robust this way, and sometimes it’s better to throw errors. There should be simple syntax to pick between them (e.g. like Rust’s
.unwrap()).- optional chaining -
That article isn’t really advocating handling _all_ errors as values AFAICS - it just doesn’t distinguish between _exceptional_ and _normal but unsuccessful_ paths.
For a wrapper around an HTTP transport, returning HTTP responses instead of raising an exception for stuff like “403 Forbidden” is probably reasonable. Their own example code is full of exceptions, though.
