The practical issue here is how to use Go effectively to handle various error/exceptional situations. For that you have to first think about and understand these scenarios and the best way to handle them. But that is not simple and context dependent! Example: I may start up N threads in parallel to search for something and when one finds it, all others are to be terminated. How do we do this? A different example: Take a function for matrix inversion. It would fail if the determinant is zero but whether this failure is an error or not depends on the context. For a certain application, if there is an alternative method that doesn’t use matrix inversion but is much slower, a failed matrix inversion is not an error but a signal to try the slower method. Another question is, in case of exception handling ala panic/recover, how to close open file descriptors to avoid leaks or do other cleanup to maintain consistent state & who does the cleanup and when? In Go you can use not just error return or panic/recover but also a chan to report things asynchronously. What makes most sense in a given situation? Then there are issues of whether to take heroic efforts to keep a program running (think a robotics control program) or to bail at the first error (and let another shard handle requests). Or whether it is ok to not lose a single request or what is an acceptable threshold in a given application. And what to do get useful debugging data out of exceptional situations. “Recover considered harmful” doesn’t quite do justice to this rich topic!
> On Apr 25, 2017, at 11:02 PM, Юрий Соколов <funny.fal...@gmail.com> wrote: > > `panic/recover` are really bad names for setjmp/longjmp. `throw/catch` are > much closer. > > And C has `assert`. You may set handler for SIGABRT, but then you have to > know what are you doing. Usually it is set for backtrace printing only. > > I mean: usual languages has clean separation between "wrong state or input", > "fast control flow" and "fatal" errors. > C has "return code + errno" for first, "setjmp/longjmp" for second and > "assert" for third. > Languages with exceptions have exceptions hierarhy with documented support > from runtime for "fatal exceptions". > > Some languages choose process isolation for recovering from fatal error (php, > erlang... .Net has domains, but looks like .Ney Core doesn't). > > Go has "return error" for first, abuses "panic/recover" for second, and in > absence of true process isolation, simply has no choice for "fatal error". > > Go should have choice for "fatal error". Since many people want to recover > from "fatal error" (and this thread shows it clearly), Go should have true > "process isolation". > > But it is just a dream. > > 26 апр. 2017 г. 8:35 AM пользователь "Bakul Shah" <ba...@bitblocks.com > <mailto:ba...@bitblocks.com>> написал: > Recover/panic need not be used only in case of a “critical” error. Just as in > the case of setjmp/longjmp, there are other useful patterns. For example, a > user may ask an interpreter to abandon its current computation by typing ^C. > This would be handled by a longjmp/panic() to regain control at the REPL > level. > > There are actually at least three use cases: > 1. Reduce the "semantic clutter" of having to check error return at every > level just because a very deeply nested function may fail > 2. Regain control as above in case of cancellation. > 3. Indicate a critical error. > > For 1. (IMHO) the best mechanism was Pascal’s non-local goto. It *only* > returned control higher up in the stack and to a lexically enclosing function > - this could be checked at compile time. In Go panic/recover are analogs of > longjmp/setjump and compile time checking is not possible to ensure that > panic doen’t escape a package scope. Also, Go allows lexical nesting of > unnamed functions but not named ones so one would not write, e.g. a parse() > function as one giant function with multiple sub functions, one each for a > parse rule. And concurrency complicates things. > >> On Apr 25, 2017, at 7:52 PM, Dave Cheney <d...@cheney.net >> <mailto:d...@cheney.net>> wrote: >> >>> Yes, and then crashes the program. In the scenario I described, with >>> thousands of other requests in flight that meet an abrubt end. That could >>> be incredibly costly, even if it's been planned for >> >> There are a host of other reasons that can take a server offline abruptly. >> It seems like a odd misallocation of resources to try to prevent one >> specific case - a goroutine panics due to a programming error or input >> validation failure -- both which are far better addressed with testing. >> >> To try to postpone the exit of a program after a critical error to me >> implies a much more complex testing and validation process that has >> identified all the shared state in the program and verified that it is >> correct in the case that a panic is caught. >> >> To me it seems simpler and more likely to have the root cause of the panic >> addressed to just let the program crash. The alternative, somehow >> firewalling the crash, and its effects on the internal state of your >> program, sounds unworkably optimistic. >> >> -- >> 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 a topic in the Google > Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/rW6LB-9N37I/unsubscribe > <https://groups.google.com/d/topic/golang-nuts/rW6LB-9N37I/unsubscribe>. > To unsubscribe from this group and all its topics, 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 > <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.
