My (admittedly limited) personal experience with writing some Go programs is that I *want* to crash on the first error by default, since I almost never know what the right thing to do is, at least not the first time I’m writing something. I’ve written my own “assert-like” function that panics to make this easier to implement (asserts are a different debate).

However, I also agree that to make something more robust and reliable, you want to handle errors correctly. I do think that making recoverable errors more explicitly visible is good, and that Go’s mechanism seems to result it slightly less pain than checked exceptions.

I do wish there was an easier way for me to get the “crash on error” behavior I want though. I also agree with James Henstridge: when you have “chained” errors, having a stack trace would make it easier to track down the ultimate source of the error.

Please see comments above.

Having used C++/Java/Python for networking software (shipped as appliances) and cloud hosted services, what I have felt is that for small scripts where special error handling is not required the “parachute exception” is ok.

But for any serious long running software GO’s error handling seems to be the right one though it may appear slightly verbose. It is really good that the GO apis clearly tells if a particular function will fail or not and encourages to handle it. Many times I miss this in python and have the experience of process crashing(and forced to do blind try:except: blocks at top level). Temporary -ve cases are pretty common in most networking software and will need to be handled at right place.The reason why appliance based software is stressed in the comment is because applying a fix to a 100 customers is not an easy and pleasant task. So an error handling paradigm (like GO) which forces programmer to think/handle at the place where it happens is the right choice.

That’s very obviously broken code if you’re using an error result, and any code review would catch it even if the programmers (which should be fired in this specific case) left it off. Now, as described in the post, the curious thing is that I cannot tell if this is correct or not if it’s using exceptions. If I get an exception out of set_off_the_bomb, was the error handled internally to prevent collateral damage, or was it overlooked as the examples in the post demonstrate? The common practice of fixing lack of error handling once an exception shows would go pretty poorly.

All of this goes back to the points in the post: the advantage isn’t that Go forces you to do anything. Bad programmers can do bad programming on any language and any error handling style. The point is that the conventions established encourage keeping the error path in mind, and that does make a great deal of a difference in practice when people are actually trying to do a good job, which is my reality.

> C is also famous for crashing in unpredictable ways with horrendously unclear error messages. And everybody who’s had a Go program with 10 goroutines crash on them knows that Go shares this characteristic too.

Go actually shows a very clean traceback for all the 10 goroutines when it does so, in a much better fashion than any concurrent programming I’ve done before that I can remember.

> Also, it just happens to be the simple solution (…) C/Go-style error handling is much, much easier to compile than exceptions. Every line of Go code with very few exceptions can lead to OOM error and there’s things like divide by zero and such).

These are truly exceptional situations and are handled as panics which work similarly to exceptions, and can be recovered from, although that’s of course rarely effective for cases such as OOM. This also kills the “they did it like that because it’s simple” argument. It does have an exception-like mechanism, and it’s consciously not used for non-exceptional things for good reasons.

> Until then, can we please stop claiming that making programs continue on encountering error conditions somehow improves programmers ? Because it’s ridiculous.

This is ridiculous indeed, and you’re the first one to mention it.

For a test for how your own error handling is, take your nearest Go program code that opens a socket. Any socket. Counter the number of different error handling paths, do you switch between v4 and v6 (and back in the case of a v6 lookup returning a mapped v4 address ?). Count the number of paths through that code. Is it less than 8 ? Sorry to tell you, but you don’t handle errors correctly. When opening a listening socket, you are properly switching it to a dual-stack socket in all cases, right ?

(if you’re interested: read why : http://long.ccaba.upc.edu/long/045Guidelines/eva/ipv6.html#guidelines )

Go doesn’t improve bad programmers who don’t have time to consider all the options. That’s impossible, it’s just partly masked by the fact that mostly only good programmers currently know Go. That’s either going to change (Go succeeds), or not (Go fails to gain traction).

Then the Go error handling will merely have switched everyone’s code from “on error, abort in a recoverable manner”, to “on error continue”.

I’m making the same argument as many have done before:

close_nuclear_bunker()
set_off_the_bomb()

In most cases, recoverable abort (ie. exceptions) is the correct course of action, and this all just sounds like an excuse to bring back a C-ism (because I don’t find the “programmers will consider errors if we make them put them in a variable !” convincing, and I’m pretty sure people like the Go authors don’t find it convincing either). Also, it just happens to be the simple solution (because for a compiler the situation is reversed, C/Go-style error handling is much, much easier to compile than exceptions, for obvious reasons. Both languages, of course, found that they did have to implement at least 2 exception types, both introduced that later on. Every line of Go code with very few exceptions can lead to OOM error and there’s things like divide by zero and such).

C is famous for having extremely brittle programs, and rightfully so. Bringing it’s error-handling style back is not a good thing. C is also famous for crashing in unpredictable ways with horrendously unclear error messages. And everybody who’s had a Go program with 10 goroutines crash on them knows that Go shares this characteristic too.

It is a matter of time till Go shares C’s reputation. Or it could fail entirely I guess. I’d prefer it to succeed.

Until then, can we please stop claiming that making programs continue on encountering error conditions somehow improves programmers ? Because it’s ridiculous.

As a bonus point, the *user* ends up knowing what actually happened as well, which is often not the case when we throw a traceback at them, let alone if the error message is bad such as the regular expression example.

I agree, though. It’s not a clear win on either side.

It’d be a shame if the answer was to use panic everywhere because it is easier to debug

As far as the regexp error goes, the quality of the error message seems to differ package by package in both Go and Python. In your example, you’ve also thrown away the information that this is a regular expression error (i.e. the exception’s type is re.error), which would be apparent if it was left uncaught, or if you were using a more constrained “except” clause.


>>> try: re.compile(")(")
... except Exception as e: print e
...
unbalanced parenthesis



m, err := regexp.MatchString(")(", "foo")
if err != nil {
    fmt.Println(err)
}
error parsing regexp: unexpected ): `)(`