On Mon, Oct 8, 2018 at 3:38 AM, Chris Hopkins <cbehopk...@gmail.com> wrote:
> 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.
Have you seen the error handling thoughts at
https://go.googlesource.com/proposal/+/master/design/go2draft.md ?
The thoughts about "errors as values" seems relevant here.
Ian
--
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.
