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.wagner...@googlemail.com> 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.levi...@capitaldata.fr>
> 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.wagner...@googlemail.com>
>> 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.levi...@capitaldata.fr> 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 <
>>>> golang-nuts@googlegroups.com> 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.
>>>>>
>>>> --
>>>> 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.
>>>>
>>>
--
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.
