> > 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...
Of course. And with your proposal it would be easy to make os.Exit
"terminating" by adding a panic at the bottom (the only exit path,
theoretical), which would make log.Fatal "terminating" in turn (the
property would have to be guaranteed though).
Anyway, I probably got the frequency I write panic("unreachable") and
the frequency I have failure at the bottom of a function mixed up. The
second is not so uncommon after all, I'm just not used to the throw
paradigm.
> Maybe I'm being dim. but I don'r understand your counter-question. Can you
> unpack it a bit?
You called this ugly:
| defer func() {
| fmt.Println("Recover:", catch("recoverable", recover()))
| }()
And this reasonable / less ugly:
| defer func() {
| fmt.Println("Recover:", catch("recoverable"))
| }()
I assumed the ugliness is about the recover logic being exposed in the
catch signature and in the handler function. If you change catch to
take the exception handler as a callback you can hide the recover
logic without language changes. But maybe there's something you want
to do that I can't see from the example.
| defer catch("recoverable", func(err error) {
| fmt.Println("Recover:", err)
| })
On Mon, Jan 27, 2020 at 5:23 AM Eric Raymond <e...@thyrsus.com> wrote:
>
>
>
> 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 a topic in the Google
> Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/u-L7PRa2Z-w/unsubscribe.
> To unsubscribe from this group and all its topics, 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.
--
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/CAEvMKD9O7uwh_xDbmBFt2Hk2YujmV%2BcL59Sm5qGWvDzJoMxB-g%40mail.gmail.com.
