A predefined handler which produces a panic appears in item (L) of
Requirements to Consider for Go 2 Error Handling
<https://gist.github.com/networkimprov/961c9caa2631ad3b95413f7d44a2c98a>
...which is a comprehensive survey of error-related issues, most of which
aren't mentioned in the draft design.
What's the use case for a function-call-specific recover?
PS: this thread is attached to an unrelated thread due to in-reply-to
header; it should be forwarded to separate it...
On Thursday, November 22, 2018 at 3:24:16 AM UTC-8, Michel Levieux wrote:
>
> I will agree with your point. Even currently, when other ways exist, it
> highly not recommended to use recover. The only time I've had to use it was
> in systems that needed to be highly available and that could not break at
> all, even on bugs or implementation failures. This is a particularly rare
> case. Maybe there'd be a way to restrict such practices to specific cases?
>
> Yes the interface thing is also a question, haven't thought about that ahah
>
> Le jeu. 22 nov. 2018 à 12:14, Axel Wagner <axel.wa...@googlemail.com
> <javascript:>> a écrit :
>
>> You're right, there is none.
>>
>> IMHO, making recovering from panics easier should be a none-goal. Panics
>> should be reserved for irrecoverable violations of invariants (i.e. bugs)
>> and not recovered, in the general case. The main reason panic/recover is
>> useful today is that it allows to elide some boilerplate, but that won't
>> matter as much when having check/handle.
>>
>> YMMV, of course.
>>
>> (there's also the secondary issue that panic takes an interface{}, not an
>> error, so it's not entirely clear what it would mean to convert a panic
>> into an error - but that's relatively minor)
>>
>> On Thu, Nov 22, 2018 at 12:08 PM Michel Levieux <m.le...@capitaldata.fr
>> <javascript:>> wrote:
>>
>>> Sure it is, I think it's part of the same problem, but (mainly for the
>>> second example) it's more complementary than it is redundant. I haven't
>>> seen a possibility for "quick recovering" in go2 draft design concerning
>>> error handling. If there is one, could anyone point it out?
>>>
>>> Le jeu. 22 nov. 2018 à 11:36, Axel Wagner <axel.wa...@googlemail.com
>>> <javascript:>> a écrit :
>>>
>>>> This seems very similar (almost identical, safe for the choice of words
>>>> maybe) to the Go 2 error handling draft design
>>>> <https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md>
>>>> .
>>>>
>>>> On Thu, Nov 22, 2018 at 11:32 AM Michel Levieux <m.le...@capitaldata.fr
>>>> <javascript:>> wrote:
>>>>
>>>>> I do like the idea, but the form looks strange IMO. I'd rather make
>>>>> the "Must" convention a new keyword for the first example, and another
>>>>> one
>>>>> for the second (though I don't see a clear keyword for that).
>>>>>
>>>>> For a panic on error you'd write :
>>>>>
>>>>> data := must error_func()
>>>>>
>>>>> Maybe the "try" keyword would be a good choice for the second example
>>>>> since it's been clearly stated that try ... catch blocks won't be
>>>>> implemented in go, which would give something like :
>>>>>
>>>>> data, err := try panic_func()
>>>>>
>>>>> But somehow it sounds quite redundant with the possibility to recover
>>>>> from panics? Don't know
>>>>>
>>>>> Le jeu. 22 nov. 2018 à 11:16, 'yinbingjun' via golang-nuts <
>>>>> golan...@googlegroups.com <javascript:>> a écrit :
>>>>>
>>>>>> For an error function:
>>>>>>
>>>>>> data, err := error_func(…..)
>>>>>>
>>>>>> can be changed to panic style:
>>>>>>
>>>>>> data := panic error_func(……)
>>>>>>
>>>>>>
>>>>>>
>>>>>> And for a panic function:
>>>>>>
>>>>>> data := panic_func(……)
>>>>>>
>>>>>> can be changed to error style:
>>>>>>
>>>>>> data, err := error panic_func(…...)
>>>>>>
>>>>>>
>>>>>>
--
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.
