Re: [go-nuts] recommend that error and panic auto coverting

2018-11-22 Thread Liam 
A predefined handler which produces a panic appears in item (L) of
Requirements to Consider for Go 2 Error Handling 


...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  > 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 > > 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 >> > a écrit :
>>>
 This seems very similar (almost identical, safe for the choice of words 
 maybe) to the Go 2 error handling draft design 
 
 .

 On Thu, Nov 22, 2018 at 11:32 AM Michel Levieux >>> > 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 > 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.

Re: [go-nuts] recommend that error and panic auto coverting

2018-11-22 Thread Michel Levieux 
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  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 
> 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 
>> a écrit :
>>
>>> This seems very similar (almost identical, safe for the choice of words
>>> maybe) to the Go 2 error handling draft design
>>> 
>>> .
>>>
>>> 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.

Re: [go-nuts] recommend that error and panic auto coverting

2018-11-22 Thread 'Axel Wagner' via golang-nuts 
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 
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 
> a écrit :
>
>> This seems very similar (almost identical, safe for the choice of words
>> maybe) to the Go 2 error handling draft design
>> 
>> .
>>
>> On Thu, Nov 22, 2018 at 11:32 AM Michel Levieux 
>> 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.

Re: [go-nuts] recommend that error and panic auto coverting

2018-11-22 Thread Michel Levieux 
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  a
écrit :

> This seems very similar (almost identical, safe for the choice of words
> maybe) to the Go 2 error handling draft design
> 
> .
>
> On Thu, Nov 22, 2018 at 11:32 AM Michel Levieux 
> 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.

Re: [go-nuts] recommend that error and panic auto coverting

2018-11-22 Thread 'Axel Wagner' via golang-nuts 
This seems very similar (almost identical, safe for the choice of words
maybe) to the Go 2 error handling draft design

.

On Thu, Nov 22, 2018 at 11:32 AM Michel Levieux 
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.

Re: [go-nuts] recommend that error and panic auto coverting

2018-11-22 Thread Michel Levieux 
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.