понедельник, 24 апреля 2017 г., 16:09:56 UTC+3 пользователь Rob 'Commander' Pike написал: > > 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 >
Rob, you just described panic as an generic exception mechanism. Then why Go has no convenient exceptions? And what about unrecoverable panic? C-style `assert`? `net/http` recovers from all panics currently, and it is clear design flaw. There should be distinction between "safe to recover" errors/panics and "have to stop execution" panics/asserts. > > On Mon, Apr 24, 2017 at 5:40 AM, 'Axel Wagner' via golang-nuts < > golan...@googlegroups.com <javascript:>> 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....@gmail.com >> <javascript:>> 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...@googlegroups.com <javascript:>. >>> 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...@googlegroups.com <javascript:>. >> 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.
