On Sunday, January 26, 2020 at 7:14:50 PM UTC-5, pboam...@gmail.com wrote: > > log.Fatal and os.Exit have the same problem. They are not "terminating > statements", so if you want them at the bottom of a function with result > parameters you have to add a panic("unreachable"). >
Excellent point. But contemplating being able to declare library functions terminating - as opposed to making it a property the compiler deduces from knowing how panic works - opens up a bigger can of worms... But I think it's very rare not to have one of the "success" paths at the > end; in 8 years it happened to me like a couple of times. Do you really > expect to have throw() at the bottom of functions? > Absolutely. Consider a parser in which your handler function for a given token or subtree consists of a bunch of if/then returns, and not matching one of them means you should throw upwards to an error handler. > > 2. A recover() call is no longer required to be within the lexical frame > of a defer(). > > Would it be less ugly like this? (with recover in the catch func.) > > | defer catch("recoverable", func(err error) { > | fmt.Println("Recover:", err) > | }) > > Maybe I'm being dim. but I don'r understand your counter-question. Can you > unpack it a bit? > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/9aac4872-b90a-4c95-9220-04b7c8acacb8%40googlegroups.com.