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.
