Your point 3 misses an important practical detail. Packages that use recover internally call panic with an identifiable type and the recover code checks whether the type is the expected one and, if not, panics again, thus behaving like any other unexpected problem.
See encoding/gob/error.go for an example. More generally, recover is excellent for isolation of errors in multi-client servers. Even more generally, blanket statements about what to do or not do with the features of a programming language are too often taken as strict rules rather than thoughtful guidelines. "Don't use panic or recover" is an example. Panic and recover are the perfect tools for some problem and prohibiting them outright eliminates some powerful designs. -rob On Mon, Apr 24, 2017 at 5:40 AM, 'Axel Wagner' via golang-nuts < golang-nuts@googlegroups.com> wrote: > My 2¢: > 1. panic if an API is clearly used wrongly. If a dev chose to not read the > docs for this one function and ignore how it's supposed to be called, then > what else have they not read the docs of? If you can detect that a program > is incorrect, failing loudly seems the right thing to do > 2. Do not panic, if an API is used correctly; this includes failing > syscalls that you'd expect to be correct if the API is correctly - your > expectations might be wrong. Return an error on non-code related problems. > 3. Don't recover, pretty much universally. Even using it as a control-flow > mechanism seems broken to me; it would hide actual programming errors that > *should* crash > 4. If you are using a library that panics and you dislike that, I see two > possible root-causes; a) you are using a library that badly coded > (according to 2) or b) your program is buggy. In either case, the correct > solution doesn't seem to paper over either bug, but to complain loudly so > it gets fixed. > 5. Be prepared for your stuff crashing, from a dev-induced panic or a > runtime-induced panic. > > And as a preventative measure: I say this as a person who was oncall while > a large service, written in a memory safe language, crashed globally and > took our service out. I know it's hard to be prepared for these things and > to recover from them, but I *still* believe that crashing is the right > thing to do. You can not prevent crashes, even globally synchronized ones, > to happen. Because programmers are just humans and humans are fallible and > stuff happens. You need to be prepared to deal with human failures. > > On Mon, Apr 24, 2017 at 2:24 PM, Sokolov Yura <funny.fal...@gmail.com> > wrote: > >> >> > Notice that real unrecoverable errors are not subject to >> defer/recover() at all. >> >> If so, then how should I raise unrecoverable error, if I really know that >> it is unrecoverable? >>> >>> Something like C style assert(): "guy, something goes completely wrong, >> and it is >> much better to stop functioning than corrupt your data further" >> >> > It's sometimes a perfectly valid and quite reasonable approach to defer >> a recover() in an API function and panic(forWhateverReason) somewhere down >> the call chain. >> > A recursive descent parser may get much simpler and easier to code, for >> example. >> >> I don't agree. I call it "abusing". In absence of other comfortable ways, >> panic is abused to unwind stack fast (upto recover). >> I could be mistaken. >> >> -- >> 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. > -- 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.
