Hacker News Reader

Comment by jeroenhd | Hacker News Reader

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).

View on HN

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.

> 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.

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.

Yeah, if all the context you want is the backtrace, that works just fine.

anyhow and thisiserror are my rust error lib defaults nowadays

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

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?

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.

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 :/

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-e...

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.

Reply on news.ycombinator.com