Thanks. Yes, that's exactly what I want, could I have Go2 now please? ;-)
Okay I'll keep doing it the way I'm doing it with a mind to swapping to
that when available.
I had avoided reading the Go2 proposal stuff simply because I regard
language design as a question for people with Marvin-like intellects.
That's way less scary than the generics proposals that worry me so much.
Thanks again
On Monday, 8 October 2018 15:33:07 UTC+1, Ian Lance Taylor wrote:
>
> On Mon, Oct 8, 2018 at 3:38 AM, Chris Hopkins <cbeho...@gmail.com
> <javascript:>> 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.
