{initial long rabley post deleted}
If I understand the exception proposals, they are quite un-go-like. That is
go as a strongly typed, "no undeclared variables", etc language sits on the
side of more effort upfront to produce fewer bugs later trade-off. Try ...
catch however is more of the rough and ready "don't worry about the details
until I absolutely have to" philosophy.
That's not to say they would be wrong for go, I just got the impression
exceptions - like interrupts - did not play well with concurrency and large
projects in general (Except in a "stop the world, I've subbed my toe" kind
of way).
I can see for many classes of problems they could work very well and
certainly be convenient, but are they not kind of a "Forget about any
issues I might have, someone else will fix it" philosophy?
{Hardware Engineer hat on}
I can't help but think that Exceptions in the hardware sense are a costly
thing, in terms of latency, context switch and the higher level handler
trying to clean up the state afterwards. In a multi-processor system this
gets MUCH worse. They are errors in the strictest sense that should be rare.
Perhaps this viewpoint is shading my outlook, of the different concept of
exceptions here.
{Hat off}
But I think that's what this is, not a question of utility, but of
philosophy, what type of language do people want go to be? Which scales to
large systems better? What is easier to understand when someone else has
written it?
I guess my fear of a catch type mechanism is coming along to find an
exception firing in someone else's code and all I see is "Out of Cheese
error", where that's an error that's used at every place in the code
anything goes wrong (I joke, but how many times have I seen code that just
goes log.Fatal("Error")). I could then come along and re-write every one of
those places to use different errors, but I would hope most people would
say that that behaviour was bad practice, to be fixed. I believe exceptions
would encourage, not discourage that behaviour.
Sorry, my short post ended up quite long too!
Regards
Chris
On Monday, 8 October 2018 16:46:28 UTC+1, Robert Engels wrote:
>
> 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 <cbeho...@gmail.com
> <javascript:>> 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...@googlegroups.com <javascript:>.
> 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.
