Go’s Errors vs Exceptions

Henri Koski
Jan 27 · 4 min read

There are already so many articles about Go’s error handling so why write yet another one? Well I would like to show why I prefer returning errors over throwing exceptions in production grade code.

Let’s get started

Imagine that we have written some web service and it’s using storage which isn’t safe for concurrent access. With this problem in mind we decide to write this simple wrapper where we synchronize access to our otherwise non concurrent storage:

Wrapper for storage to make it safe for concurrent access

Now we have wrapped the underlying Add function call with sync.Mutex and made it safe to call from different goroutines. Some of you might think why not defer the Unlock() call. Well in this case we don’t want to pay the overhead of defer and clearly we can see that there is no actual need for it. Lock, Add, Unlock; clean, linear and easy to follow. Nice job!

The part of software that uses our code might look something like this:

SafeStorage in use

The implementation of storage changes

Months go by and our sweet web service just keeps running nice and smooth. Satisfied with our work we decide to reward ourself with a nice trip to GopherCon. While heading down to San Diego our fellow gopher had to change the underlying storage implementation in a way which make’s it possible to return an error:

New implementation of underlying storage

Now our colleague is trying to call NewSafeStorage with FailingStorage as an argument. But as we gophers know that wont do, and compiler is kind enough to tell us why:

*FailingStorage does not implement Storage (wrong type for Add method)
have Add(string, string) error
want Add(string, string)

With the help of compiler our fellow gopher is able to refactor our SafeStorage and see right away that now it makes perfect sense to defer the call of Unlock():

Make Add method return error

After refactoring the SafeStorage the final implementation might look something like this:

SafeStorage in use with error handling

And there we have it! Explicit error handling made it easy and safe to refactor the codebase and our well deserved trip to GopherCon was able to continue without interruptions.

What if Go had exceptions instead?

Let’s imagine for a while that instead of errors we would have exceptions. Our code might look something like this:

SafeStorage in use with exceptions

Instead of explicitly saying that Add function returns an error we would have been throwing exception. Looks quite nice doesn’t it and we didn’t even have to change the signature of Add function! Since that signature didn’t change there is no reason to even look at SafeStorage implementation. Also the exception is handled so no reason for our compiler to cry about it, right?

Our fellow gopher deploys the change while we are getting ready for David Cheney’s speak at GopherCon. Just when the talk is about to start we get a message: SafeStorage has a Deadlock!

The problem with exceptions

In real world our fellow gopher would have most likely caught this error and fixed it right a way. But then again in the real world problems aren’t always this simple and errors might propagate through multiple layers with much more complex functions.

While the code base keeps growing and multiple people work on it, the chance that someone is catching the exception in wrong level get’s higher. And if I was able to demonstrate this problem with less than 100 lines of code, what are the changes of this happening when someone touches year old project with thousands of lines of code?

Exceptions allow functions to return in places you cannot see just by looking at the code. That behavior makes it harder to maintain the codebase.

Exceptions allow functions to return in places you cannot see just by looking at the code. That behavior makes it harder to maintain the codebase. For some Python script that might be completely fine but for production grade code I wouldn’t say so.

Conclusion

Two main reasons why I favor Go’s error handling model over exceptions are:

  1. It forces me to pay more attention to error handling
  2. It keeps the programs execution flow linear

The second point there is crucial for maintainable code and as a matter of fact Google has banned the use of exceptions in their C++ mostly for that reason.

The one argument in favor of exceptions is the amount of if err != nil checks you have to write when returning errors. This is something that is supposed to be taken care of in Go 2 with the checked expression.

In the end of the day, robust and maintainable codebase outweighs the ability to write bit less code, at least for me.

Thanks for reading!

Henri Koski

Written by

Freelancing Go enthusiastic

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade