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.
