The Go designers considered and discarded exceptions for common errors, then added panic/recover for truly exceptional circumstance. There are known problems with try/catch: https://en.wikipedia.org/wiki/Exception_handling#Criticism
I've posted a comprehensive list of "possible requirements" for Go2 error handling. If it's missing any concepts that try/catch provides, could you raise them? https://gist.github.com/networkimprov/961c9caa2631ad3b95413f7d44a2c98a That page is linked from the feedback wiki I posted previously. On Monday, October 8, 2018 at 10:37:43 AM UTC-7, Robert Engels wrote: > > 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 <cbeho...@gmail.com > <javascript:>> 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. >> >> > -- 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.
