On 24 April 2017 at 14:09, Rob Pike <r...@golang.org> wrote: > 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.
I've certainly used both these techniques in the past, but I'm no longer entirely sure whether this really is "excellent". It's so easy to have code that relies on non-deferred cleanup of state that invokes some code that happens to panic (whether with a known type or not), leading to hard-to-debug problems that would have been considerably easier if the whole thing had just crashed. In general, the only time I'd now consider using the "panic with identifiable type" technique is in recursive descent parsers and the like, where the domain is severely constrained and the convenience of being able to use the results of called functions directly is great. That said, my most recent use was to exit early from sort.Search when an unexpected error occurred talking to the network. Useful but arguably a bit dirty. rog. -- 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.
