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. An exception is never ignored. Either it’s handled or it reaches the top and stops the whole thing. With value as errors, the default is exactly the opposite.
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 ?? DEFAULT instead of x = 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()).
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.
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. An exception is never ignored. Either it’s handled or it reaches the top and stops the whole thing. With value as errors, the default is exactly the opposite.
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:
x = y?.z ?? DEFAULTinstead ofx = y.z if y else DEFAULT(esp for nontrivial nesting)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()).@SittingWave @mac
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.