Go error handling

https://code.ohloh.net/search?s=%22if%20err%20!%3D%20nil%22&pp=0&fe=go&mp=1&ml=0&me=1&md=1&ff=1&filterChecked=true

by reinhardt • 12 years ago

47 98 12 years ago

code.ohloh.net

martinml• 12 years ago

On GitHub:

https://github.com/search?q=%22if+err+%21%3D+nil%22+extensio...

JensRantil• 12 years ago

I don't see what's interesting with this?

Artemis2• 12 years ago

Yeah, I don't get the point of this; that's how it's done in Go. You might want to search "catch (Exception e)" for other languages.

royjacobs2• 12 years ago

Except in Go you would be manually "rethrowing" exceptions whereas in other languages that is done automatically.

norswap2• 12 years ago

I think it shows that while the Go people usually say that their error handling is better than exception, most often they either exit on exception (which is like not catching an exception) or pass the error up the call stack (the default behaviour for an uncaught exception). This means that this way of doing error handling is actually just verbose.

Which is also my opinion.

sagichmal4• 12 years ago

    > most often they either exit on exception (which is like
    > not catching an exception)

Not really. Exiting on error is an explicit decision that you make, hopefully only in your top-level (func main) scoping block. Letting an exception bubble up to that level without catching it is invisible.

    > or pass the error up the call stack (the default 
    > behaviour for an uncaught exception)

The crucial difference, which the Go team takes great pains to elucidate and fans of exceptions never seem to acknowledge, is that by treating the error as a first-order value, you make its propagation up the call stack explicit, in the normal i.e. visible code path. That makes reasoning about your error path a lot easier, and makes producing code that handles errors correctly a lot simpler.

The "Eureka" of error handling in Go isn't a massive thing. It's just the reification of the small and important understanding that errors are values, just like anything else.

smcl• 12 years ago

Maybe it would be better use the title of the submission to draw attention to exactly what is interesting here. All I can see is "lots of people use 'err' as the name of their returned error value in Go code on ohloh"

barrkel3• 12 years ago

Most of the time, the only things done with an error are fatal exit or panic - the same code, over and over and over again.

It looks much worse than exceptions. (Except C++ and Java exceptions, as both are exception anti-patterns in different ways.)

NateDad18• 12 years ago

I don't know what codebases this covers, but GOOD Go code does not panic.

Intermernet• 12 years ago

Is this meant to be a negative comment on Go error handling not conforming to a single pattern, or a positive comment on Go error handling not needing to conform to a single pattern?

Or is it just a random code search posted on HN?

danielheath• 12 years ago

It's natural that most public code panics on error, even though it's bad practice.

Error return values (e.g. go) are better for building large systems where stability & predictability are important (that is, cost to maintain).

Exceptions are better for quickly building systems (that is, cost to build).

threeseed2• 12 years ago

You have that completely backwards.

Exceptions are much better for large systems. You can define standardised behaviour regardless of where an error occurs. You can let unexpected errors 'bubble up' and be managed in a way that preserves the integrity of the system. You have the flexibility to recover from errors and let errors be silenced.

There is unparalleled flexibility with exceptions. Go's approach is frankly arcane.

MetaCosm2• 12 years ago

You are 100% right on unparalleled flexibility. Why limit your self to one set of flow control operators when you can have two! Also, lets make one break out of another one at any point of exception! The flexibility is endless!

You are 100% right, it is terrifyingly flexible. There is a reason exceptions as flow control is considered an anti-pattern.

huntaub• 12 years ago

I don't seem to understand what about returning error values stops any flexibility. I have built several things in Golang, and you absolutely have the ability to continue to return error values ("bubbling up") until a function has the ability to handle or silence it.

I get the personal preference one way or another, but can you go into more detail about what specific features one loses with Go's approach?

vardump7• 12 years ago

Exceptions are much better for large systems.

I deal with systems that contain millions* of lines of C++. Exceptions are killing us. How much larger do we need to get until I can expect to see the advantages?

* I haven't actually counted those lines or even wc -l'd them.

lomnakkus• 12 years ago

Those are claims that need some serious evidence to back them.

raphael_kimmig• 12 years ago

This is really interesting to me because it shows what to think of the claim that explicit error handling makes go code more reliable than languages which use exceptions.

When using go I often get the feeling of doing something wrong. Because I know I'm supposed to "handle errors" but all I really want is the program to blow up and hand me a stack trace. This gives me the worst of both worlds, I have to manually trigger something that approaches the unhandled exception behavior of other languages while retaining the verbosity of explicit errors returns. Now it seems like I'm not the only person struggling with this.

Has anyone come up with a sane approach to that problem?

MetaCosm2• 12 years ago

I wouldn't say "more reliable" -- I would say "easier to reason about". Errors are just another returned variable, nothing more, nothing less. Go doesn't encourage tracking two independent flow control sets -- one for exception flow, and one for normal program flow. I have seen all sorts of complex nastiness created via the multiple flow control sets in Java.

I write server code the runs for long periods of time, the amount of times I want to blow up and get a stack trace is exceptional low, only when continuing to run is more harmful than having the service completely down.

As for just wanting it to blow up -- just ignore the error handling, it will blow up. Instead of putting the error in a variable, just throw it away using _ ... and the next dependent thing will blow up. Not very elegant, but it will remove all the boilerplate you don't like, and it will crash hard like you do like... alternatively write a crashOnError(err error) function and call that passing in error -- and all it has to do is if (err != nil) { panic(err) }

sagichmal4• 12 years ago

    > Because I know I'm supposed to "handle errors" but 
    > all I really want is the program to blow up and hand me 
    > a stack trace . . . Has anyone come up with a sane 
    > approach to that problem?

Yeah, stop doing that :) Code your error path first, add your program logic afterwards. It's a shift in the way you think when writing programs, but it's a good shift and it makes your code more robust.

NateDad18• 12 years ago

For tiny programs you use yourself "blowing up" is fine. For code in production, it's probably not. Thinking about what can go wrong and writing code to handle it ahead of time is a large part of software engineering. If the network times out trying to download that file, what do you do? Do you blow up? Or do you retry a few times first? Do you pass the error back and let the caller do the retry? This is the stuff Go makes you think about. This is what makes your programs more robust. Things break in the real world, good code handles that gracefully. Blowing up is not graceful.

orangeduck• 12 years ago

So I get it, and it makes a good point, but this could be more of a symptom than a disease.

When I first started programming C I also tended to just exit the program on getting a bad return code, because I'd never been taught how to properly handle errors - I'd always just replied on exceptions.

Only later did I start to get bitten, and take proper care to handle errors sensibly and explicitly.

As "go" is such a new language I wouldn't be surprised if a similar thing has happened to new programmers migrating over to it.

cjslep• 12 years ago

I find that I wind up "bubbling up" errors of my own to build a stack trace yet still retain control of my program, like:

  func LowLevelCode() (int, error) {
    // rest of body...
    if /* error condition */ {
      return 0, errors.New("LowLevelCode error: " + /* error description */)
    }
  }

  func MiddleWare() (interface{}, error) {
    // body of code...
    nCount, err := LowLevelCode()
    if err != nil {
      return nil, errors.New("MiddleWare error: " + err.Error())
    }
  }

  func ApplicationCode() {
    // Do cool stuff...
    obj, err := MiddleWare()
    if err != nil {
      log.Println(err) // Prints "MiddleWare error: LowLevelCode error: " + ...
      // Handle on a high level, retry connections, etc.
    }
  }

I'm hoping someone comes in and corrects me with a more elegant way of "building up your own stack trace" without having to do this manually and without panic.

vardump7• 12 years ago

This is what I used.

http://golang.org/pkg/runtime/#Stack

NateDad18• 12 years ago

There are a lot of error handling libraries out there. On Juju, we're working on one right now. This is the preliminary version: https://github.com/juju/errgo

Basically you just call a function every time you would return an error, and it automatically records the file and line number and lets you add on some context to the message, plus it gives you the option to mask the type of the error (to hide implementation details from your callers).

I wouldn't use errgo right now, it's still under heavy development, but it's similar to a lot of other error handling libraries out there.

leaveyou2• 12 years ago

If you search for "err != nil" it returns more: 13,153

Jabbles• 12 years ago

Does anyone know the total number of lines of Go on Github? Without knowing that this number is meaningless.

hornetblack• 12 years ago

I find that a mustBeNil function is useful:

    func mustBeNil(err error) {
        if err != nil {
            panic(err)
            // or log.Fatal(err)
        }
    }

    func mustBeNil(err error, msg string) {
        if err != nil {
            log.Fatalf("%s: %s", err, msg)
        }
    }

;Edit: brackets

FiloSottile• 12 years ago

Please, pull that `panic(err)` line. It is widely accepted that is bad practice, and something you should not do.

You panic when a program is expected to crash because of irrecoverable corruption. Only.

sagichmal4• 12 years ago

    > You panic when a program is expected to crash because of 
    > irrecoverable corruption.

Or programmer error.

dscrd4• 12 years ago

mustNotBe?

NateDad18• 12 years ago

Don't panic in the middle of your code. You can occasionally use panic during init() when it indicates a programmer error. Otherwise, just return an error.

dscrd4• 12 years ago

Note that the other two hip languages of the moment, Rust and Swift, also do not rely on exceptions for error management.

arianvanp• 12 years ago

I like erlang's model here. Fail often and fail fast and let the supervisor of that particular node just restart the thing. Bug fixing comes later when you inspect your logs. Do errors bubble up in actors in go like they do in erlang?

tomp• 12 years ago

How is that different from exceptions, really? It's just less granular, but exactly what e.g. Django (a Python web framework) foes with exceptions (per-request, not per-process).

pilif• 12 years ago

This higlights a point why I actually prefer exceptions to manually passing around error codes.

If any of these calls to panic() are inside libraries, by using that library, you will put yourself into a position where your application will exit without giving you any recourse to fix it.

I've seen too many C libraries doing this too - "mmh - I can't handle this right now - let me just call exit()" (last time this happened was inside a commerical library for reading excel files. If it was confronted with a file that was corrupt in some way, the library would call exit(), terminating my application server in the process. Thanks)

With exceptions, a library can just throw but I as a consumer of the library at least get a chance to handle the error somehow and who knows - I might be able to find some way to still proceed and not crash.

If I don't handle that exception, oh well, then I crash anyways, but that's not different from the library calling exit or panic.

With exceptions, I also never risk that I (or a library I use) forgets to check for an exit code and proceeds to corrupt data (or crash way later at a seemingly unrelated point).

When I fail to catch an exception, I my application dies.

When I fail to check an error code, my application might possibly corrupt data.

Just because implementing exceptions in compiled languages is difficult and messy (C++) and because exceptions are slow doesn't mean we shouldn't be using them. It means that we have to improve our language and OSes in order for them to work without hacks and quickly enough because, honestly, the value they provide to me is big enough to warrant a bit of research.

Tobani4• 12 years ago

Panic is not exit. http://golang.org/pkg/os/#Exit is exit

Panic is throw. Recover is an isomorphism for catch.

For the most part. You have to explicitly ignore error codes in go. (Not that you can't handle them incorrectly.)

NateDad18• 12 years ago

"In order to ignore error codes in go, you must do so explicitly". - FTFY

robryk2• 12 years ago

You have to explicitly ignore error codes in go. (Not that you can't handle them incorrectly.)

I'm not sure I udnerstand what you mean. I can write: fmt.Fprint(os.Stdout, "Something\n")

This returns an error, which I silently discard. Did you mean something else?

NateDad18• 12 years ago

So, as others said, panic is very similar to throw, it's just intentionally ugly and strongly discouraged.

There are linters which will tell you when you forget to check an error code.

You say that unhandled errors can cause data corruption, but what about improperly cleaning up resources? That happens all the time... you have your data partially written to disk and something throws an exception, if you don't have your cleanup code in a try/finally, then bam, corrupt data. That's a lot more likely with the mindset of generally just letting exceptions fly.

WorldWideWayne5• 12 years ago

> but what about improperly cleaning up resources?

What about it? Are you saying that error return values somehow force programmers to properly cleanup resources?

> That happens all the time...

How are you quantifying that? I write code in exception bearing languages all the time and never have this problem. Why would you begin a partial write and then call some code that would likely produce errors or exceptions? That sounds like a recipe for corrupt data no matter the style of error catching. A better way would be to use a method of writing that is basically atomic.

A lot of your arguments in this thread sound a bit contrived.

dragonwriter5• 12 years ago

So, as others said, panic is very similar to throw, it's just intentionally ugly and strongly discouraged.

I thought it was officially only discouraged across module boundaries -- e.g., library code shouldn't let panics "escape".

logicchains• 12 years ago

I've found in some cases Go's style of error handling can actually make for great documentation: when every third line of code is something like

  if err != nil{ 
    log.Printf("This specific operation %v went
       wrong because input %v was %v or was expected to be %v but 
       wasn't", operationName, inputName, actualInput,
       expectedInput)
  }

Then reading the error messages gives a pretty good idea of what's supposed to be happening at that point in the code.

NateDad18• 12 years ago

Here's why Go's errors are better than exceptions:

Multithreaded environments make exception handling next to impossible to do correctly. The stack trace only shows a single thread which is often useless without more context. Exceptions are per-thread, so handling has to be per-thread.

Exceptions make the control flow of your program completely obscure. Any line that calls out to another function can cause this function to exit. If you're not wrapping every function call in a try/finally, you're probably doing it wrong (at which point it's even more verbose than go's error returns).

Errors in Go aren't special. They're just values returned from a function. You have the whole language at your disposal to deal with them.

I can write this in Go, and it's perfectly safe:

  f, err := os.Open(filename)
  if err != nil {
     return fmt.Errorf("Failed to open config file: %s", err)
  }
  err = callFunctionThatMightErrorOut()
  if err != nil {
    // handle err
  }
  f.Close()

I know that my code will ALWAYS close that file handle. To do the same thing in a language with exceptions, you'd have to do something like this:

  File f
  try {
      try {
          f = os.Open(filename)
      }
      catch(Exception e) {
          throw new Exception(string.Format("Failed to open config file: %s", e.Message))
      }
      try {
          callFunctionThatMightErrorOut()
      }
      catch(Exception e) {
          // handle error
      }
  }
  finally {
      if f != nil {
          f.Close()
      }  
  }

Now who's verbose?

The reason people think Go exception handling is verbose is because they aren't really handling errors in their own code. Go makes it easy to handle errors in the right way.

dllthomas9• 12 years ago

Your exception code ignores RAII, which is about the best argument for exceptions. The file should be closed as soon as the function returns for any reason, which (with a sensible design and properly implemented destructors) will be as soon as the function returns for any reason, meaning the outside try-finally is entirely unnecessary and the file is guaranteed freed even if you have multiple returns.

vardump7• 12 years ago

Golang has defer. http://golang.org/doc/effective_go.html#defer

That's what grandparent post should have been using.

  f, err := os.Open(filename)
  if err != nil {
     return fmt.Errorf("Failed to open config file: %s", err)
  }
  defer f.Close() // This is going to be always executed when leaving this function
  err = callFunctionThatMightErrorOut()
  ...

When writing C++, I wish I had defer over RAII. In C++, when interfacing with lower levels or C code, you need to first wrap everything in a class. Just so that you can use unique_ptr or shared_ptr etc. Or worse, write a scoping class. Ugh. Ugly and so many lines written for nothing...

NateDad18• 12 years ago

RAII can get rid of that one try/finally, that's true. I was writing standard Java/C#/Python-eque code, however, which requires all those try/catches.

Here's what you get if you have some magic RAII file-closer object:

  try {
     f = os.Open(filename)
  }
  catch(Exception e) {
      throw new Exception(string.Format("Failed to open config file: %s", e.Message))
  }
  try {
      callFunctionThatMightErrorOut()
  }
  catch(Exception e) {
      // handle error
  }

Still not great.

WorldWideWayne5• 12 years ago

And here's what it might have looked like if they had taken notes from a language with a good exception handling style:

  using(File f = os.Open(filename)) {
    callFunctionThatMightErrorOut()
  }

Thanks to exceptions, `using` doesn't have to access the return value from `os.Open`, it just has to handle the exception that it (or any code inside the `using` block) might raise. Also thanks to exceptions, using can automatically cleanup `File`. Without exceptions, this simple pattern would not work very well at all.

amatheus• 12 years ago

The code will close the file in case of a panic?

todd8• 12 years ago

One goal, while writing programs, is to construct programs that operate correctly (that is conform to the specifications that we have or imagine for the finished product). Complex control flows make reasoning about correctness difficult. Consider a simple loop:

  while x != y
    x = ...
    y = ...
  end while
  -- (A)

At point (A) we know that x == y. This allows us to reason about what happens next in the program. Having a break statement within the loop means that we now have a more complex condition to consider at the end of the loop.

  while x != y
    x = ...
    if x == 0: break
    y = ...
  end while
  -- (B)

At point (B) we know that x == y or x == 0.

Once we introduce exceptions, we can end up outside the loop without knowing anything about the state of x and y (unless we examine a lot more code, possibly code quite remote from this little loop we are working on).

go's requirement to laboriously check and handle every function return may make it easier to reason about x and y in our little example, but it comes at the cost of extra boilerplate error checking everywhere. This too hurts our ability to reason about the code we are writing by increasing verbosity, so I'm not sure that go's approach will work out much better than some form of exceptions mechanism.

However, I welcome this approach to language design, keeping the language as simple as possible, but no simpler. Even if go error handling turns out in practice to be roughly as good as C++'s approach, it will be a big win for go because go ends up smaller, simpler, and easier to learn and master. It's difficult to assemble a team of C++ programmers to work on complex systems because it is so hard to find more than a handful of real C++ experts at a time. I feel safer recommending the use of go to a typical programming team than C++.

Go error handling

Related Stories