Hacker News Reader

Comment by Animats | Hacker News Reader

Is this just someone's proposal, or a formal addition to Go, or what?

"All errors must implement the Error interface." That's a step forward.

Rust really has the same error handling as Go - return an error status. But the syntax is cleaner. Rust thrashed around with errors at first. Then things sort of settled down. At this point, everybody uses Result<UsefulValue, Error>, but "Error" is just a trait that doesn't require much information. And "?" for propagating errors upwards is a huge convenience.

It's probably too late to retrofit "Result" and "?" into Go libraries, although they'd fit the language.

View on HN

> Rust really has the same error handling as Go

Not at all. Rust has proper sum types, that it can return just like anything else in the language, while Go has a special cased error return slot (one may be tempted to call it an ugly hack), and it can return a value on both, which it does in some standard library calls.

Not at all. Go has an error type, and Go functions have the ability to return zero, one, two, or more items, ordered however the developer likes. An error may be among those, as desired, and populated as desired.

Some software also writes to both STDOUT and STDERR.

I know, special cased may have been better worded as "just a convention". My point is, this is not much different than using a thread-local variable, like errno, and adds useless confusion - your return values represent n*m values, while there is only n+m case with proper error semantics.

Re STDERR: but shells don't decide whether a program execution failed on having written to STDERR, but by the returned singular error code.

I agree with everything you've written in this comment.

I'd like to split a hair here and say, this is a "Go's standard library" problem, and not a "Go language" problem.

Good API design for a software package should have proper error semantics.

Good API design for a language, allows for flexibility in actual implementation, alongside standards that say "you SHOULD do this".

Disagree. This level of convention is inseparable from the language.

Not doing the conventional error return in go would be akin to using a Return sum type in reverse, putting the success value into the Error case..

One of the issues in Go is that if all you ever do if "if err != nil { return err }", you will quickly run in to problems because you will have errors like "open foo: no such file or directory" or "sql: no rows in result set" without a clue where that error came from. Sometimes that's obvious, often it's not.

I'm not sure how Rust handles that? But it's more than just "propagate errors", but more like "propagate errors with the appropriate context for this specific error".

Rust uses the `?` operator to convert between error types which allows for users and libraries to hook in to the error before its returned.

There are a number of helper libraries that provide an extended type erased error type to attach a real stack trace to the error, such as `anyhow`. These helper libraries also provide ways to attach extra metadata to the error so you can do things like `returns_a_result().context("couldn't do it")?` so you can quickly annotate the error. The standard library is support for this through a `context.Value` like api on the Error trait. The std lib `Error` trait also has functions for find the cause of the error and traverse a collected chain of errors, very similar to go's `errors.Cause` api.

Rust also has a number of libraries for making specific error types like `thiserror` which can help generate error enums with the implementations required to carry backtraces, context and causes.

Yep, if you want wrapped errors in Rust, you use the anyhow crate. It leans heavily into dyn so has some performance tradeoffs, but it's roughly the same performance-wise as Go's error interface (which also uses a vtable under the hood).

Though using a dynamic error in Rust should only impose an allocation cost on the error path, and I presume Go is the same.

Reply on news.ycombinator.com