[raphael_kimmig]

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?

[MetaCosm]

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) }

[NateDad]

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.

[sagichmal]

    > 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.