Hi,
Could I please check what current error handling best practice is?
I've gotten quite smitten with github.com/pkg/errors. I really like the
ability to create a stack of errors that trace to what is going on. However
it seems this is not an often used package - it's not available in
playground for example. It's really useful for diagnostics to see a stack
of what is causing an error, however in my latest application where I'm
trying to be really rigorous with my error handling I've hit - for want of
a better word - an imperfection. Could I check if there's a better way to
do these things:
So here's what I'm doing:
When I have an error I need to report I create it like this:
var ErrInvalidVariable = errors.New("Invalid Variable")
Which means that you can have code that nicely reads:
if err == ErrInvalidVariable { /* handle this error */}
It's how the os package reports errors (along with helper functions), so I
assume this is the correct way.
For better debug I can use errors.Wrap to annotate this error through the
error stack and get useful diagnostic printouts such as
Line Processing passed "if $BOB==3": Token Passed $BOB : Invalid Variable.
So far so good. This starts to fail though if I'm trying to determine lets
say a fileio error that came from the config file reader, vs the script
file reader. At the moment I can say
_, err := os.Open(...)
if err != nil {
return errors.Wrap(err, "Config File read error")
}
But without searching through the error text I can't tell who caused that.
Now I could declare a specific type for this, add a Cause handler onto
that, but it starts to get clunky to do that for every error condition.
Also it doesn't scale to more than 2 levels because it stops at the first
cause found. I can obviously work around this, but I'm thinking I'm doing
this wrong, a defining feature of go is the error handling - surely there's
a better way to do it than this!.
Am I doing something unusual here and wanting to determine where in the
hierarchy of the stack a problem might have come from? How else do people
handle errors in situations like this, where you can't fully handle them
locally, so you want to return the error, but then when you get to the
higher levels you can handle them, as long as you have information about
the error. The annoying thing is, everything is there in the string of the
error message and I could strings.Contains my way through the error string
to work this out, but that feels a really stupid way to do this.
I also come across this in my test cases, I want to inject error to make
sure I am spotting errors correctly and checking that I am getting the
correct error from the correct place is really quite clunky at the moment,
if I could test that an error checker in location X was triggered by it
being passed an error that would save me a lot of code.
Any suggestions gratefully received.
Regards
Chris
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
