Yes, lobby to have Go2 include exceptions and then you don’t need to worry
about any of this... :)
> On Oct 8, 2018, at 5: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.
>
> 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.
--
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.
