Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Exploring Error Handling Patterns in Go

8thlight.com

Post reply on HN
Print view View original

11–20 of 80 posts

Re: Exploring Error Handling Patterns in Go

#11

Post by divan »

I wish more developers could do "investigation" like this for a new languages they learn.

For me, the main difference between Go's way of handling language and the rest of mainstream languages is that it makes error handling unmagical.

It literally says – errors are just like any other return values. Let's say, if you have function `sqrt` and return a value, and then call this function – you probably is interested in this return value and should handle it somehow (or mute with `_`). Now, the same applies for errors - if function returns the error, you likely to think how to handle it – do something in place or propagate up the stack.

There is also a cultural moment to this. As we mostly learn by examples, and most Go code has proper error checks (not equal to "proper error handling" but nevertheless), it makes newcomers to do the same as well, even while disagreeing with Go's way. I've heard from many devs that Go was the reason that made them appreciate proper error handling.

And honestly, I feel this too, and I think the reason is that in Go it's too easy to "handle errors properly". I never had this feeling with languages with exceptions, where I had to read whole books (!) just to learn how to properly use them and be confident in the way how I handle errors. (this is just an example, not the spark to start return values vs exceptions battle, just in case)

Re: Exploring Error Handling Patterns in Go

#12

Post by BreakfastB0b »

rco8786 wrote: post #4

if err != nil return err if err != nil return err if err != nil return err https://github.com/docker/cli/search?q=%22if+err+%21%3D+nil%... https://github.com/kubernetes/kubernetes/search?q=%22if+err+... https://github.com/coreos/etcd/search?q=%22return+err%22&uns... https://github.com/influxdata/influxdb/search?q=%22if+err+%2... The reality of Go's error handling is that you just implement exactly what exception bubb…

Error/Either monads are the perfect middle ground IMHO. You get errors as data types and an efficient way to abstract away the boilerplate associated with it.

Re: Exploring Error Handling Patterns in Go

#13

Post by erik_seaberg »

divan wrote: post #11

I wish more developers could do "investigation" like this for a new languages they learn. For me, the main difference between Go's way of handling language and the rest of mainstream languages is that it makes error handling unmagical . It literally says – errors are just like any other return values. Let's say, if you have function `sqrt` and return a value, and then call this function – you probably is interested i…

The flipside of easy-to-learn is there's no payoff for getting better with the language. Your code will always be exactly as tedious as novices' code because they'd rather conserve compiler cycles than spend them to amplify programmers' work.

Re: Exploring Error Handling Patterns in Go

#14

Post by lucio »

chmike wrote: post #7
rco8786 wrote: post #4

if err != nil return err if err != nil return err if err != nil return err https://github.com/docker/cli/search?q=%22if+err+%21%3D+nil%... https://github.com/kubernetes/kubernetes/search?q=%22if+err+... https://github.com/coreos/etcd/search?q=%22return+err%22&uns... https://github.com/influxdata/influxdb/search?q=%22if+err+%2... The reality of Go's error handling is that you just implement exactly what exception bubb…

This is not correct. Exceptions do different things than report an error. They unwind the stack. That's why they are called exceptions and not errors. One important benefit of Go's error handling pattern is readability. With exceptions, it's not easy to see who handles it and where. There is indeed less code, and that's nice for the writer, but from the reader perspective, error handling becomes obscure. And from the…

Let's imagine a syntax-sugared Go...

Every function has a hidden "err" return value

Every function has an "exceptionExit:" block, by default it does just "return err;"

After every function call, an automatic "if err != nil {goto exceptionExit}" is added.

You can add an "exception" block to a function, it replaces the default.

Now you have function level exceptions in Go just by syntax sugar, without stack unwinding and without requiring new compiler functionality, just syntax sugar.

Re: Exploring Error Handling Patterns in Go

#15

Post by dfischer »

erik_seaberg wrote: post #13
divan wrote: post #11

I wish more developers could do "investigation" like this for a new languages they learn. For me, the main difference between Go's way of handling language and the rest of mainstream languages is that it makes error handling unmagical . It literally says – errors are just like any other return values. Let's say, if you have function `sqrt` and return a value, and then call this function – you probably is interested i…

The flipside of easy-to-learn is there's no payoff for getting better with the language. Your code will always be exactly as tedious as novices' code because they'd rather conserve compiler cycles than spend them to amplify programmers' work.

Consistency in reading a code base amplifies work.

Re: Exploring Error Handling Patterns in Go

#17

Post by dfischer »

h1d wrote: post #10
chmike wrote: post #7

Earlier quoted context omitted.

This is not correct. Exceptions do different things than report an error. They unwind the stack. That's why they are called exceptions and not errors. One important benefit of Go's error handling pattern is readability. With exceptions, it's not easy to see who handles it and where. There is indeed less code, and that's nice for the writer, but from the reader perspective, error handling becomes obscure. And from the…

At the cost of making the entire logic's readability less which to me is more important than sometimes getting confused where errors bubble up to. The philosophy is different when, for example the author of Ruby wanted to make coding fun for programmers and does a good job at it and Go is sticking to 'this must be right' approach and breaks some people's heart. Personally I'd appreciate being more 'fun'.

I used ruby for a long time and Go more recently. I think Go is fun. I’m able to read code bases with consistency. In a lot of Ruby apps, I see creative flexing that is unique to that person, or teams style.

The fun part is getting code written, and shipped. And it stays fun when it’s maintainable and production ready.

I’m having a lot of fun shipping Go code. :) I definitely can understand a codebase a lot faster than a random ruby one. That may be a personal thing but it works for me.

Re: Exploring Error Handling Patterns in Go

#18

Post by dullgiulio »

A cursory look at the article, shows that the most important observation about error handling in Go is missing.

Errors should be "decorated" (wrapped, contextualized...) in 99% of the cases.

In the end you get errors that describe step by step what your program tried to do and why it failed, for example:

* could not load profile: could not open file: permission denied.

* could not download profile image: could not open URL: HTTP GET failed: network is down.

This has many advantages:

1. Much more readable than stack traces (especially if they include source file and line information or exception class names: users don't care about those.)

2. Errors are still easy to grep in code to work out the program flow (the stack trace, basically.)

3. When reading the code, you can see from the error context strings what the code is actually doing. Basically it serves a function of comments and (unlike comments) error strings remain up to date.

It is definitely verbose, especially the not equal nil part, as it's a result of Go attempt not to have special cases. Also it's a pity that errors can be silently ignored: maybe Go2 could be stricter here.

Overall, I think this is one of the best approaches at error handling.

Re: Exploring Error Handling Patterns in Go

#19

Post by pebers »

erik_seaberg wrote: post #13
divan wrote: post #11

I wish more developers could do "investigation" like this for a new languages they learn. For me, the main difference between Go's way of handling language and the rest of mainstream languages is that it makes error handling unmagical . It literally says – errors are just like any other return values. Let's say, if you have function `sqrt` and return a value, and then call this function – you probably is interested i…

The flipside of easy-to-learn is there's no payoff for getting better with the language. Your code will always be exactly as tedious as novices' code because they'd rather conserve compiler cycles than spend them to amplify programmers' work.

On the bright side, your code will always be as easy to understand as a novice's code too, so it conserves other programmer's mental cycles as well.

Re: Exploring Error Handling Patterns in Go

#20

Post by golangnews »

erik_seaberg wrote: post #13
divan wrote: post #11

I wish more developers could do "investigation" like this for a new languages they learn. For me, the main difference between Go's way of handling language and the rest of mainstream languages is that it makes error handling unmagical . It literally says – errors are just like any other return values. Let's say, if you have function `sqrt` and return a value, and then call this function – you probably is interested i…

The flipside of easy-to-learn is there's no payoff for getting better with the language. Your code will always be exactly as tedious as novices' code because they'd rather conserve compiler cycles than spend them to amplify programmers' work.

That's a feature, not a bug. It means I don't have to deal with anyone's 'clever' code.

It's not about saving the compiler work at all, it's about saving the hundreds of humans who have to read your code after you the work of understanding the abstractions you created.

Post reply on HN