Hacker News Reader

Comment by ohazi | Hacker News Reader

A lot of the Rust developers I've spoken with don't really consider using unwrap everywhere the way that Go programmers use "if err != nil" to be proper error handling. Most of them consider it an ugly hack to be used when playing around or testing something.

The value that most people see in Rust's error types is in error transformation and propagation, which let you do things like correctly handling edge cases when using closures without cluttering up the logic of the success case.

If you are going to compare unwrap/expect to "if err != nil" -- Rust's advantage is that it forces you to at least pretend to handle the error, while Go will happily keep chugging along even if you never inspect err.

View on HN

> Rust's advantage is that it forces you to at least pretend to handle the error

I'm not sure I would call this an advantage. See: Handling of Checked Exceptions in Java.

Sort of seems even worse in that there is no built in way to propagate the error if you don't want to handle it. At least with Java you just added the exception to the throws declaration of your function if you didn't want to handle it. Here you have to do something about it or manually do something to propagate it? I think the failure of checked exceptions in Java to be a really interesting example to study for language designers, because on the surface, it seems like it was mostly a good idea. Yet in practice it was nearly universally disliked.

When in Java you add a method call with an exception you either handle it or add the method call and the exception type to the list. In Rust when you add a method call that has a Result, you either handle it or add ? to the end of it to propagate the error, auto converting to the appropriate error type. The experience is much better than on Java, while still properly documenting where failures can happen and what isn't being handled.

> you either handle it or add ? to the end of it to propagate the error, auto converting to the appropriate error type

But that can only happen if the method returns a type of Result, true? Does this have the effect that just about every function ends up having to return Result (so that the ? operator works)?

Pretty much, which means that the existence of fallible functions is exposed or handled. The big difference with explicit exceptions in Java is that Rust has enums that let you encode every error (so the type checker shows you when you add a new error type where you haven't handled it) so the list of possible errors goes in your enum, not the function definition or alternatively lets you rely on trait objects, which you can't match on but you don't care about when moving them around, which can be equivalent to relying on the root of the an object inheritance tree.

> Sort of seems even worse in that there is no built in way to propagate the error if you don't want to handle it.

That's better, not worse, because it means you don't up with unhandled downstream errors bloating the signature just because people didn't want to bother with them, which means people are more likely to do something sensible (which may just be wrapping) with them.

Checked expressions suffered from a woefully insufficient language to describe what might be thrown. For instance, there was no good way to type a map function.

Reply on news.ycombinator.com