I don’t think any of hat is true. Java has exceptions, it is highly concurrent
and it is very efficient.
I just think that by the time yo get all of the “features” into Go error
handling that it needs for both reliability, debugging, etc., you are going to
end up with “exceptions” just with a different name and syntax - so I say - why
not just implement them to begin with. Passing errors up stream (which is often
the only reasonable thing to do in a complex system) is error prone without
stack traces (for logging), and types (for handling).
The only difference between Go and Java here would be that Go’s are interface
based, where as in Java it uses a type hierarchy based off Throwable.
You can write poor Go error code now, there would be nothing stopping someone
from writing poor error code using exceptions, except at least with exceptions
it is obvious (by the catch and throw clauses) which errors the code is
handling and how… (if at all in bad code). With the current Go error handling
and the ability to use ‘_’ coupled with no API that controls what errors can be
seen/emitted (other than reading the specific API method documentation, and
even here you have to get lucky, including with the stdlib methods) - complex
error situations in Go are much harder to handle.
Simple situations are easy in Go right now, but the ‘error mechanism’ is more
flow control than error handling in many cases.
> On Oct 8, 2018, at 12:07 PM, Chris Hopkins <cbehopk...@gmail.com> wrote:
>
> {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 <>> 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
>> > <http://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
>> <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 <>.
>> For more options, visit https://groups.google.com/d/optout
>> <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
> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout
> <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.
