Python errors as values: Comparing useful patterns from Rust and Go
1–10 of 77 posts
Re: Python errors as values: Comparing useful patterns from Rust and Go
#2In FileMonger[0], which uses Tauri, I have implemented a `Result` logic for errors in TS, similar to what's available in Rust. It's clunkier, but still much preferable to the mess of throwing. Much easier to handle errors and debug.
Re: Python errors as values: Comparing useful patterns from Rust and Go
#3Oh, good, heavyweight error handling just in time for py3.11's zero-cost exception happy path.
But, more generously: why not simply return an error, and use isinstance(val, Error) for error handling? Making objects and calling functions is quite costly, and that can largely be avoided.
Re: Python errors as values: Comparing useful patterns from Rust and Go
#4One problem I’ve experienced doing something like this is you end up with both exceptions and error values since the standard library and 3rd party libraries are still primarily exception based. You either have to live with it or create wrappers that catch errors and return them as values.
Re: Python errors as values: Comparing useful patterns from Rust and Go
#5In FileMonger[0], which uses Tauri, I have implemented a `Result` logic for errors in TS, similar to what's available in Rust. It's clunkier, but still much preferable to the mess of throwing. Much easier to handle errors and debug. [0] https://filemonger.app/
I don't know Python too well but I think this is covered in TFA. There's a comparison between a Result type using https://github.com/rustedpy/result and an ADT/sum type — and the sum type looks like it's way more ergonomic with Python's current typechecker.
While I like Rust — and Result works really well with `?` — it doesn't actually look like that's the best pattern for Python?
Re: Python errors as values: Comparing useful patterns from Rust and Go
#6I'm six months into my Python journey. We aren't building a library, so everything runs on 3.11. Having spent most of my career in statically typed and sometimes functional languages, I've found the result package approach and pattern-matching suggestion work well. There's been a suggestion it's not very Pythonic, but I'm willing to continue using a result monad because the trade-off is one-sided; it comfortably pays for itself.
Re: Python errors as values: Comparing useful patterns from Rust and Go
#7One problem I’ve experienced doing something like this is you end up with both exceptions and error values since the standard library and 3rd party libraries are still primarily exception based. You either have to live with it or create wrappers that catch errors and return them as values.
We write wrappers for standard and third-party libraries that throw errors. For example, we have our own dump_json function that catches-and-returns errors thrown by json.dumps.
We didn't need many wrappers given the nature of our SDK, but some programs will need many wrappers and that could get unwieldy
Re: Python errors as values: Comparing useful patterns from Rust and Go
#8> Rust returns returns errors using a "wrapper" type called Result. A Result contains both a non-error value (Ok) and an error value (Err)
A `Result` can contain either a non-error value (Result::Ok) or and error value (Result::Err), never both.
Re: Python errors as values: Comparing useful patterns from Rust and Go
#9Why does the author want to swallow these exceptions? Let them propagate and it's obvious where the issue lies. If you can't handle an exception, don't catch it.
> It's impossible to know which line might throw an error without reading the functions themselves... and the functions those functions call... and the functions those functions call. Some thorough engineers may document thrown errors but documentation is untested and therefore untrustworthy. Java is a little better because it forces you to declare uncaught errors in method signatures.
The author's proposal doesn't change this as much as they think it does. You still don't know what type of errors a function will throw without inspecting the code and thus how to resolve them. Unless, you have a blanket switch for every possible error anything could return which is the very thing they are complaining about.
Re: Python errors as values: Comparing useful patterns from Rust and Go
#10I'm six months into my Python journey. We aren't building a library, so everything runs on 3.11. Having spent most of my career in statically typed and sometimes functional languages, I've found the result package approach and pattern-matching suggestion work well. There's been a suggestion it's not very Pythonic, but I'm willing to continue using a result monad because the trade-off is one-sided; it comfortably pays…
What is a result monad?