I would agree that error handling should be made more explicit. But
keeping up with line numbers / stack traces / other book keeping info?
That's busywork handling, not error handling. Error handling should be
the steps needed to recover from the error or fail if recovery isn't

Doing the debugging in gdb is nice, but it isn't always possible. For code
that is deployed elsewhere that has intermittent and hard to reproduce
errors, its very useful to have line-numbers and stack traces
automatically available. Does this mean for every error case I have to
roll my own error wrappers to capture this info? For a language that
tries to do the right thing and minimize programmer overhead, Go's approach
to error handling appears half baked.

On Thursday, October 11, 2012 3:51:11 PM UTC-7, Jesse McNelis wrote:

On Fri, Oct 12, 2012 at 8:47 AM, NotCarl <not...@google.com <javascript:>>
I have been working with Go for the past two days and have noticed that a
lot of niceties of error handling in other languages are either missing or
hard to find.
Go has it's own niceties.
* Line numbers.
If you want to include a line number in an error you can call
* Stack traces.
To include a stack trace in your error call
* Error propagation. For more than one level of stack depth, error handling
becomes complicated. Maybe some middle-of-the-stack function is not
prepared to handle the error. Is the only option to just "return nil,
Yep, you return it up to the point at which it can be handled.
The explicit return makes the fact that a function can error obvious
and encourages developers to think about the error handling
requirements of their code.
ie. code that has horrible error handling requirements tends to look
horrible and is a pain to use.


Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 5 of 12 | next ›
Discussion Overview
groupgolang-nuts @
postedOct 11, '12 at 10:09p
activeOct 12, '12 at 6:33a



site design / logo © 2022 Grokbase