Hacker News Reader

I would love to see some in-depth discussion about this. Even in 2022, I don't think it's clear what we want error handling to look like. You can ask for correctness guarantees from the compiler, but it's easy to ask, it's harder to design a system that actually works.

> The lack of exhaustive switch case statements makes this worse because the compiler doesn't care if you're handling all the expected error types (or unexpected ones).

I would love to see how this is supposed to work.

My first thought here is checked exceptions in Java. With checked exceptions, you have a specific set of exceptions that a function is supposed to generate, and a compile-time error if those exceptions are not either handled or propagated. This turned out to be a bit of a disaster in actual practice, and I'm not sure what the fix would look like here.

I'm generally a bit miserable when I try to deal with error handling in Rust, believe it or not.

As for the err != nil boilerplate, I've seen some proposals but I haven't seen anything that was clearly a good proposal. The generics proposal was clearly good, IMO, just for a point of reference.

> I'm generally a bit miserable when I try to deal with error handling in Rust, believe it or not.

Likewise. I'm a big Rust user, use it for all my personal projects, but error handling is totally unsolved there.

- Friction around mapping between error types if I need to "add context and rethrow"

- Often lack of stack/trace information for custom error types. Something went wrong the the DB query? Great! Where? Which line of code?

There are solutions for these, I try them, and I'm sure someone will pipe up mentioning them (e.g. anyhow, thiserror, miette, etc), but its just so much damn ceremony to do it properly at a particular call site, especially when you are mixing your own code with library code and each library's unique snowflake error types, that I don't do it consistently.

In Rust you can use the anyhow library if you want a similar level of overhead to Go and similarly aren’t worried about differentiating error cases.

What do you think of adopting Zig’s error handling approaches to Go?

> [...] and similarly aren’t worried about differentiating error cases.

I differentiate error cases in Go, so I'm not sure what you're talking about. Sometimes it's done with ==, other times it's done with type assertions, type switches, and some helper functions in the errors package.

I've barely touched Zig.

I think it's contributing some important ideas, and maybe those ideas will get further developed in newer languages.

I'd like stuff like

myFunc() works as today

myFunc()^ returns the err if there is one

myFunc()! panics if there is an err

> myFunc()! panics if there is an err

You can do this with generics today:

  func must[T](val T, err error) T {
    if err != nil {
      panic(err.Error())
    }
    return val
  }

  //usage example
  file := must(os.Create("out.txt"))
  defer file.Close()
  bytesWritten := must(file.Write([]byte("Hello World\n")))

We have something like this in our internal utility library. I'm getting some serious mileage out of this when using Go as a script language, where error propagation is not as important as for a regular application or a library.

> myFunc()^ returns the err if there is one

You can also do this with generics:

  func geterr[T](val T, err error) {
    return err
  }

It is true that must() and geterr() are slightly more verbose than single-character operators, but I'd argue having a word instead of a symbol is much more readable. Besides, ^ cannot be used as a postfix unary operator because it's already a binary operator. That would create a grammar ambiguity.

I don't think any option should panic on error. I've had to deal with programs that panic on error and the way I dealt with it was by forking the project and removing every call to panic(). It's even worse with libraries.

The other problem is that it's super common to want to wrap the error somehow when returning it. Often you want to wrap the error differently depending on where the error came from in the function, like this:

  d, err := os.ReadFile(fname)
  if err != nil {
    return err // unwrapped
  }
  x, err := parseX(d)
  if err != nil {
    return fmt.Errorf("%s: %w", fname)
  }

I know that not all Go developers write good error handling code. However, I don't want to make it easier to write bad error handling code if you're not making it correspondingly easier to write good error handling code.

Aborting is almost always the correct answer in order that you get a core dump that may be debugged post-mortem. Blindly continuing when in an invalid state is a horrible idea.

Unless you put the function name somewhere in the error, there is no way to know where something happened. "Some thing didn't write properly? Cool! Where and which line?"

> "Some thing didn't write properly? Cool! Where and which line?"

My eyes glaze over when I'm trying to read stack traces in Java or Python, and then it turns out I can't figure out what's wrong because the stack trace doesn't include the path of the file that failed to parse.

What we care about is stuff like:

- Program tried to parse file X,

- Failed because file X doesn't exist, or because file contains syntax errors, or something

- Some context giving us the reason why program tried to read file X, which is usually at a fairly high level (something like "could not load config").

Putting the function name in the error-handling code is something that you SOMETIMES do, but only when it adds important context. If you do it all the time you end up with something completely unreadable, like a stack trace. There are various libraries you can use that give you stack traces for errors in Go, if that's what you want.

If I get an error that X is not a valid JSON file--often, that's all I need to know, because I can open X and see the syntax error and fix it. Knowing the name of the function that detected the syntax error is unhelpful, usually, and we have logging + debuggers to help with those cases.

Java stack-traces are extraordinarily informative - they give line number, class, method and even offset inside relative lambda when an exception occurs. Few languages do better and Go is not one of them.

If it's an internal (unexpected) error, panic. You get a backtrace and everything--which helps because it was an unexpected internal error, so you probably messed up. You'd like to know where that is.

But if it's an actual user-visible error code then that means you expected for this error to happen eventually and you designed for it. Why then do you need a backtrace? You program is doing what it's supposed to.

I mean sure while developing it's nice to be able to just replace the error code emission by panic (which I do sometimes)--but in regular operation? It doesn't help the user at all.

> I've seen some proposals but I haven't seen anything that was clearly a good proposal

I have one! Allowing inline ifs, like this:

    err := func()
    if err != nil { return err }

1 line instead of 3 for simple error handling, yeaah

I am quite convinced that Zig's approach to error handling would apply well to Golang. At least adding a "try" prefix would be an easy change. Add the ability to enable/disable an error return trace and that would do a good enough job handling the majority of error handling boilerplate.

    * https://ziglang.org/documentation/master/#try
    * https://ziglang.org/documentation/master/#Error-Return-Traces

I am working on adding this to the compiler now but I know of no actual process for getting such an improvement officially into the Go language.

There are several other concepts in Zig that enhance safety that Go can consider adopting. I personally prefer the soundness of Rust, but Zig is much more philosophically aligned with Go. In error handling alone, we can consider adopting a "catch" suffix as Zig has for when "try" is insufficient as well as error sets. Additionally optional types seem like they would work well in Go.

    * https://ziglang.org/documentation/master/#Optionals
    * https://ziglang.org/documentation/master/#Error-Set-Type

If I'm reading your feedback correctly it sounds like you want:

1) Syntactic sugar for if err != nil { return err }; similar to ? in Rust

2) The errcheck linter to be enforced (part of go vet, maybe?)

3) Exhaustive switch statements

The first point was looked at and no one has proposed a solution enough of the community could agree was an improvement while maintaining sufficient explicitness. If someone has a really good proposal for this I am sure it would be considered.

The second point could probably happen with enough lobbying. So, verbosity is still there but at least every project will do something with their errors.

The third point I don't believe is possible today because of the way interfaces work. If Go added sum types then this should be possible, but I could be mistaken about that.

1) Yes I didn't want to make the tired comparisons to Rust but Rust does have the excellent syntactic sugar for returning errors. Of course, something like this is hampered by the lack of sum types and the ambiguous zero values in Go which makes it more difficult for the compiler to know what to return but I hope we eventually get there or we find another way to do this

2) I'm not a fan of leaving error checking to linting. It would be fantastic if the compiler would stop for mishandled errors. It already doesn't compile for banal things like unused imports and variables

3) It's not really a matter of wanting exhaustive switch statements as such but if this was present, it would make error handling much simpler, again a la Rust (I'm sorry)

These are all hopes and wishes to make the language better to work with and I'm sure if we get anything close to any of this, it would be a while. The Go governance seems to move very slowly and deliberately considering how long it took them to wake up to adding generics but we can still dream

> > Syntactic sugar for if err != nil { return err }; similar to ? in Rust

> Yes I didn't want to make the tired comparisons to Rust but Rust does have the excellent syntactic sugar for returning errors.

Many people seem to forget that Rust didn't start (even in its 1.0 release) with the ? operator. It started with the try!() macro, which expanded to something not unlike Go's "if err != nil { return err }". The ? operator was added later, as a shortcut to the same semantics as the macro except for also being able to work with Option instead of just Result, based on developer experience with the macro (the two major annoyances being not being able to use the macro with Option, and the nesting when chaining several uses of the macro).

If Rust was able to create the ? operator based on developer experience with its try!() macro, I don't see why Go won't be able to create its own error propagation operator based on developer experience with its "if err != nil { return err }" idioms.

> If Rust was able to create the ? operator based on developer experience with its try!() macro, I don't see why Go won't be able to create its own error propagation operator based on developer experience with its "if err != nil { return err }" idioms.

Because Go does not have declarative macros. So while Rust got something like 25 versions out of try! before considering that it’s worth an operator (but it could well have gone with an other pattern if one had arisen) that’s not really an option for go.

> 1) Syntactic sugar for if err != nil { return err }; similar to ? in Rust

IMO they could exactly use what you wrote, ie. change gofmt to have it all on one line like that. The biggest annoyance with the error return boilerplate is the waste of vertical space and just squashing it into 1 line would fix that.

Or perhaps allow variable assignment to be used in the same scope.

if x, err := someMethod(); err != nil { return err }

x <- is usable here.

The bigger issue is that returning the error without wrapping provides zero context and after a crash you're stuck trying to figure out which of a hundred calls to Write was responsible for "write error" or some other equally ambiguous message that's nearly impossible to track down.

So you have to resort to a poor man's stack trace: if err != nil { return fmt.Errorf("my thing: %w", err) }

(We use wrapcheck via golangci-lint to enforce it because not having context for an error has bitten us so many times)

Things I tend to do in my firmware for errors.

Record the error line number where the error happened. Use __builtin_return_address(0) to fink on the caller.

Idle thoughts. Despite it's provenience BASIC's on error goto has merit. The problem with try/catch is creating scoped blocks of code that's annoying.

   try
   {
     // scoped stuff
   }
   catch
   {
   }

vs

   on_error_goto label;

   // stuff

   label:

Also a thought is having a separate error_return keyword. And the ability to mark functions with 'no error'

The thing with try/catch is that many times, code that throws doesn't have to be handled on the call site! So you can easily have a happy path and kick the bucket to a location where the error can ACTUALLY be handled property.

Go doesn't have errors, only values. Value handling could be improved, I'm sure, but anything that focuses on values that humans attach error meaning to is fundamentally flawed and will leave broken half-solutions.

Each problem people say Go has with error handling is actually a more general problem with value handling and/or interfaces and the right solution would solve for those problems across the board. The problems are real, but not related to errors specifically.

There are always going to be cases where the happy path call tree should be abandoned because no useful value meeting requirements is going to be possible. What’s needed is to persuade Go devs to use panics instead of obscuring every function reinventing them by hand.

The happy path should at least have a value that we oft categorize as error to branch on meaningfully. If the code has no purpose it wouldn’t need to be called.

panic is certainly appropriate if programmer error left the application in an inconsistent state (an exceptional state, or exception for short as it is often referred to). I've never seen a Go developer, or developer in any other language for that matter, try to deal with these cases by hand.

> You don't have compile time checks for errors.

I don't quite understand this statement. The compiler finds errors in my code all the time. Should it be evaluating something like `if err != nil`?

A real problem is when something like this occurs

    x, err := thisFuncFails();
    // some other lines of code, but err is not checked
    x.callMethod(); // this crashes at runtime

unless you explicitly ignore `err`, the compiler shouldn't allow you to use `x` without checking err. In Rust/Zig this is accomplished with the union types, which doesn't allow to use `x` until you have checked it's not an error. This is also very useful for Option types; and I wish it was in Go since the beginning as having `nil` in the language is a huge mistake.

The problem is worst with procedural functions

os.Mkdir("foo")

looks pretty innocent but with no return value to use, the compiler is no help in reminding you this is a fallible function

add errcheck and ineffassign to your build script. the compiler should really do this itself.

I guess what he is saying is that

x, _ := someFunc() shouldn't compile if someFunc has error returns.

That syntax basically means "I am deliberately not handling error returns". I always pair it with a comment that explains why I can do that. It comes up. A common one for me for instance is using .Write([]byte) (int, error) on a bytes.Buffer. Because that .Write implements an interface that has an error return, there's an error return, but a byte buffer can never fail to .Write. (If it does due to memory running out, I don't think it ever comes back as an error, just the process terminating.)

There's no point being more particular about it... there's no practical way to force a programmer to handle an error, especially in light of the fact that "do nothing with the error" is also a perfectly acceptable thing to do! (Example: Writing a JSON document out as the result of an HTTP API call. I don't want to log every such error, because that just crufts up my logs, I don't need metrics on this particular system, and once the HTTP stream is broken there's nowhere left to write an error out to the user, so... discard it is.)

Ah, that makes sense. I wonder if a compiler flag would be a good compromise? As a way to report unhandled errors, but still let it compile.

> You don't have compile time checks for errors.

Doesn't the fact that errors are values, combined with the fact that you cannot ignore values (except explicitly by assigning them to "_"), provide compile time check for errors?

Not really. Go thinks this is fine (on mobile, forgive me if I get this wrong).

    foo, err := foo()
    if err != nil { 
        return nil, err
    }
    
    bar, err := bar(foo)
    
    return bar, nil

The problem occurs because go only cares if a variable is used once per definition. Not once per assignment.

You are right, I have missed that, as I have written under the sibling comment.

Though I'd like to ask - does that scenario really happen in practice? It is idiomatic to handle every error right after the function call that returns the error. To me, the lack of "if err != nil {" under the "bar(foo)" call really stings my eyes.

I know, compile time checking is different from "it doesn't happen in practice". It's a tradeoff. I'm just wondering about the magnitude of the impact.

You're looking at a minimal test case, not an example of it happening in real production code. Of course it's obvious in the minimal test case, that's the point.

I've personally written something akin to the following, which triggered no errors (at the time, maybe this is fixed):

    foo, err := foo()
    if err != nil { 
        nil, err
    }

    return foo, nil

The worst part is because all of the error-handling is copypasta boilerplate, your eyes don't look at it. So subtle bugs get through and make it to production. I've seen this one too:

    foo, err := foo()
    if err != nil { 
        return foo, nil
    }

    return foo, nil

Also note that now we've gone from "Doesn't [go] provide compile time check for errors?" to "Well I guess it doesn't check that errors are used, but that would never happen to me."

> Also note that now we've gone from "Doesn't [go] provide compile time check for errors?" to "Well I guess it doesn't check that errors are used, but that would never happen to me."

True, but there was also a "you are right" in between :)

> does that scenario really happen in practice

It does happen, I've seen it several times, and even other insidious examples that linters did not catch. When you're dealing with a code base that is constantly changes, things like that end up happening.

Not really. It's idiomatic to use a single "err" variable for every error value in the same function body, and the compiler will only check whether that variable is used at least once; it doesn't perform a data flow analysis to ensure that every value that might be assigned is used.

So if you assign 10 different error results to the same variable at various points, but only actually check it 9 times and forget the 10th, the compiler will not tell you that anything's wrong.

You are right. I forgot about that case.

Perhaps variable re-declarations (via := operator) would be a good addition to Go. Compiler could optimize the code to re-use the variables when possible, but the semantics of the language would force the programmer to handle each and every error.