I read the proposal and the only knock against including a stack trace by
default is one google problem cited that was clearly bad error handling to
begin with.
Why is there always some need to reinvent the wheel. Leave Go error handling as
in and add a throws and catch that new code can use, with the current const
based error instances - just add an interface Exception that all throw X need
to implement in order to use, and catch on interfaces, not structs.
> On Oct 8, 2018, at 9:54 AM, Chris Hopkins <cbehopk...@gmail.com> wrote:
>
> 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> 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.
--
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.
