4 ms·

There's no functional difference between Go and Rust here, other than that the Rust code you seem to interact with doesn't seem to bother wrapping errors as oft

There's no functional difference between Go and Rust here, other than that the Rust code you seem to interact with doesn't seem to bother wrapping errors as often. Neither languages have very good errors. Then again, no language I know does errors well; I'd like Java's error system if Java developers didn't insist on making every exception a runtime exception you can't know you need to handle unless you read the source code. FWIW, you may be able to see the stack traces by enabling them in an environment variable (export RUST_BACKTRACE=1). By default, errors are dumped without context, but enabling back traces may show stack traces as well as detailed human-written context (if such crates are in use).

tsimionescu 1y ago
There is a difference between Go and Rust on the error ha sling front. In Go, the error handling is forced to be so verbose that adding a little bit of context doesn't significantly increase code size/effort, so programmers tend to actually add that context. Also, there is a very simple function for adding context to errors in the stdlib itself, fmt.Errorf. In contrast, the difference in Rust between just returning an error (a ? at the end of the expression that can return one) vs adding context is much higher. Especially so since the standard library doesn't offer any kind of error context, so you either have to roll your own or use some error handling crate (apparently anyhow is very popular). So, while at the language level there is little difference, the ecosystem and "incentives" are quite different.
- dllthomas 1y ago
  > the difference in Rust between just returning an error (a ? at the end of the expression that can return one) vs adding context is much higher I don't disagree with what you've said, but I think this is likely to be read too strongly. Adding a map_err before the ? is only a big step up in verbosity because the ? alone is so very terse.
  - lesuorac 1y ago
    I just always make my own error type and as part of their creation throw a backtrace into the struct. Then using `?` gives me a stack trace for free.
    - dllthomas 1y ago
      Yeah, if all the context you want is the backtrace, that works just fine.
- tough 1y ago
  anyhow and thisiserror are my rust error lib defaults nowadays
sfn42 1y ago
I like Java's exceptions. I've been working in C# and i really miss checked exceptions. Feels like if you use them well they're a great tool, but sadly a lot of devs just don't use the available tools very well.
- lesuorac 1y ago
  The problem with checked exceptions in Java is that pretty much every language feature added since then has assumed unchecked exceptions (use an IO operation in a stream). So they start to stick out in a lot of places :/
  - Expurple 1y ago
    Hi, I'm the author of the article. As I've learned when discussing my older article about exceptions, the real problem is that methods can't have an unknown, generic, composable set of checked exceptions! https://home.expurple.me/posts/rust-solves-the-issues-with-exceptions/#checked-exceptions-in-java https://home.expurple.me/posts/rust-solves-the-issues-with-e...
    - lesuorac 1y ago
      Generics were added later than checked exceptions. You're just providing more examples of my argument that new language features are not made with checked exceptions in mind.
Mawr 1y ago
Yeah, so that's not how anything humans do works. Languages are designed for humans, so you must analyze from the perspective of humans. You can't merely compare "functional differences" and call it a day. Watch this until the end: https://youtu.be/MmPtfy9P714?t=101 https://youtu.be/MmPtfy9P714?t=101 So now, what's more likely, that someone is just going to slap a "?" at the end of a line and be done with it or that they're going to, unprompted, research error handling libraries, choose and install one, then go out of their way to add context to each line?

tsimionescu 1y ago

There is a difference between Go and Rust on the error ha sling front. In Go, the error handling is forced to be so verbose that adding a little bit of context doesn't significantly increase code size/effort, so programmers tend to actually add that context. Also, there is a very simple function for adding context to errors in the stdlib itself, fmt.Errorf. In contrast, the difference in Rust between just returning an error (a ? at the end of the expression that can return one) vs adding context is much higher. Especially so since the standard library doesn't offer any kind of error context, so you either have to roll your own or use some error handling crate (apparently anyhow is very popular). So, while at the language level there is little difference, the ecosystem and "incentives" are quite different.

dllthomas 1y ago
> the difference in Rust between just returning an error (a ? at the end of the expression that can return one) vs adding context is much higher I don't disagree with what you've said, but I think this is likely to be read too strongly. Adding a map_err before the ? is only a big step up in verbosity because the ? alone is so very terse.
- lesuorac 1y ago
  I just always make my own error type and as part of their creation throw a backtrace into the struct. Then using `?` gives me a stack trace for free.
  - dllthomas 1y ago
    Yeah, if all the context you want is the backtrace, that works just fine.
tough 1y ago
anyhow and thisiserror are my rust error lib defaults nowadays

sfn42 1y ago

I like Java's exceptions. I've been working in C# and i really miss checked exceptions. Feels like if you use them well they're a great tool, but sadly a lot of devs just don't use the available tools very well.

lesuorac 1y ago
The problem with checked exceptions in Java is that pretty much every language feature added since then has assumed unchecked exceptions (use an IO operation in a stream). So they start to stick out in a lot of places :/
- Expurple 1y ago
  Hi, I'm the author of the article. As I've learned when discussing my older article about exceptions, the real problem is that methods can't have an unknown, generic, composable set of checked exceptions! https://home.expurple.me/posts/rust-solves-the-issues-with-exceptions/#checked-exceptions-in-java https://home.expurple.me/posts/rust-solves-the-issues-with-e...
  - lesuorac 1y ago
    Generics were added later than checked exceptions. You're just providing more examples of my argument that new language features are not made with checked exceptions in mind.

Mawr 1y ago

Yeah, so that's not how anything humans do works. Languages are designed for humans, so you must analyze from the perspective of humans. You can't merely compare "functional differences" and call it a day. Watch this until the end: https://youtu.be/MmPtfy9P714?t=101 https://youtu.be/MmPtfy9P714?t=101 So now, what's more likely, that someone is just going to slap a "?" at the end of a line and be done with it or that they're going to, unprompted, research error handling libraries, choose and install one, then go out of their way to add context to each line?