Re: [go-nuts] Methods of reflect pkg use mostly panic instead of return error. Why so?
On Wed, 2022-07-20 at 22:51 +0200, 'Axel Wagner' via golang-nuts wrote: > The reason reflect uses panic, is for convenience. It would be > inconvenient having to check an error at every reflect call. The other reason is that a panic in reflect is as close as you can get in runtime to a compile error, which is what the non-reflect based equivalents would generally give you for the errors that panic in reflect. Dan -- 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/db3c17c326f72d37e975c64337e4dd6cd2640b5c.camel%40kortschak.io.
Re: [go-nuts] Methods of reflect pkg use mostly panic instead of return error. Why so?
Which is also the distinction between checked and unchecked exceptions. Checked
exceptions force the caller to deal with potential errors and are harder to
ignore than error codes.
> On Jul 20, 2022, at 3:52 PM, 'Axel Wagner' via golang-nuts
> wrote:
>
>
> The reason reflect uses panic, is for convenience. It would be inconvenient
> having to check an error at every reflect call.
>
> Personally, I strongly disagree with the advice you quote by Dave. Mainly,
> because it doesn't actually tell you what "truly exceptional" means.
> To me, the rule of thumb is:
>
> 1. Return an error, if the source of a problem is in the interaction of the
> process with the outside world (and can thus be fixed by the user).
> 2. Panic, if the source of a problem is a bug in the program (and can thus
> only be fixed by the developer).
>
> reflect APIs are passed a type, so as a rule, any problem when using them is
> internal to the program - types can't be passed from outside the process. It
> indicates that the user of reflect did not code carefully enough and that
> they should add extra checks to prevent that panic.
>
> Of course, there are libraries which use reflect on behalf of *their* user
> and which might operate based on external input. For example, encoding/json
> uses reflect to look up and set field names in the JSON input. However, it's
> the job of those libraries to then do those checks safely and translate them
> into errors appropriately.
>
> If you keep to the "panic means bug and error means external error source"
> rule of thumb, this also means that if you check if json.Unmarshal returns an
> error that error is always be fixed by the user (by providing a different
> JSON source). If, OTOH, json.Unmarshal would return errors when it
> incorrectly uses reflect, a user might get an error like "can't set
> unaddressable value in line marshal.go:1234", which is utterly inactionable
> to them.
>
> Of course, it's a rule of thumb and there will be edge-cases. But, in
> general, I find it extremely helpful and in the vast majority of cases very
> clear.
>
>> On Wed, Jul 20, 2022 at 9:35 PM Uvelichitel wrote:
>> Hi, for sure i know final Go proverb -- "Don`t panic". Also Dave.Cheney "The
>> simple rule of thumb is panic should only be used in truely exceptional
>> cases, which, as their name suggests are rare."
>> Also I know there are exist circumstances where explicit panic() call looks
>> reasonable.
>> I`d like to know what are the reasons in package reflect to use panic()
>> instead of return error.
>> I`m working on not much epic (have about 2 readers) post about using
>> panic() in stdlib.
>> To say
>> $ grep -r "panic(" $GOROOT/src | wc -l
>> gave 3218 occurrences of explicit panic() call in stdlib. Really
>> impressive not panicking)
>> But design choice in reflect package intriguing me mostly.
>> Would be much appreciated for hints.
>>
>> --
>> 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/a8c61abf-a236-47d9-99a4-ad907412f427n%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/CAEkBMfFbqhk2atF_omJ1D70YbY1Mp%2BERf-1AGviUnZtpD%3DBxFA%40mail.gmail.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/BF145AB7-336C-4A5A-9D4F-0AD69BF1C5E3%40ix.netcom.com.
Re: [go-nuts] Methods of reflect pkg use mostly panic instead of return error. Why so?
The reason reflect uses panic, is for convenience. It would be inconvenient
having to check an error at every reflect call.
Personally, I strongly disagree with the advice you quote by Dave. Mainly,
because it doesn't actually tell you what "truly exceptional" means.
To me, the rule of thumb is:
1. Return an error, if the source of a problem is in the interaction of the
process with the outside world (and can thus be fixed by the user).
2. Panic, if the source of a problem is a bug in the program (and can thus
only be fixed by the developer).
reflect APIs are passed a type, so as a rule, any problem when using them
is internal to the program - types can't be passed from outside the
process. It indicates that the user of reflect did not code carefully
enough and that they should add extra checks to prevent that panic.
Of course, there are libraries which use reflect on behalf of *their* user
and which might operate based on external input. For example, encoding/json
uses reflect to look up and set field names in the JSON input. However,
it's the job of those libraries to then do those checks safely and
translate them into errors appropriately.
If you keep to the "panic means bug and error means external error source"
rule of thumb, this also means that if you check if json.Unmarshal returns
an error that error is always be fixed by the user (by providing a
different JSON source). If, OTOH, json.Unmarshal would return errors when
it incorrectly uses reflect, a user might get an error like "can't set
unaddressable value in line marshal.go:1234", which is utterly inactionable
to them.
Of course, it's a rule of thumb and there will be edge-cases. But, in
general, I find it extremely helpful and in the vast majority of cases very
clear.
On Wed, Jul 20, 2022 at 9:35 PM Uvelichitel wrote:
> Hi, for sure i know final Go proverb -- "Don`t panic". Also Dave.Cheney
> "The simple rule of thumb is panic should only be used in truely
> exceptional cases, which, as their name suggests are rare."
> Also I know there are exist circumstances where explicit panic() call
> looks reasonable.
> I`d like to know what are the reasons in package reflect to use panic()
> instead of return error.
> I`m working on not much epic (have about 2 readers) post about using
> panic() in stdlib.
> To say
> $ grep -r "panic(" $GOROOT/src | wc -l
> gave 3218 occurrences of explicit panic() call in stdlib. Really
> impressive not panicking)
> But design choice in reflect package intriguing me mostly.
> Would be much appreciated for hints.
>
> --
> 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/a8c61abf-a236-47d9-99a4-ad907412f427n%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/CAEkBMfFbqhk2atF_omJ1D70YbY1Mp%2BERf-1AGviUnZtpD%3DBxFA%40mail.gmail.com.
[go-nuts] Methods of reflect pkg use mostly panic instead of return error. Why so?
Hi, for sure i know final Go proverb -- "Don`t panic". Also Dave.Cheney
"The simple rule of thumb is panic should only be used in truely
exceptional cases, which, as their name suggests are rare."
Also I know there are exist circumstances where explicit panic() call looks
reasonable.
I`d like to know what are the reasons in package reflect to use panic()
instead of return error.
I`m working on not much epic (have about 2 readers) post about using
panic() in stdlib.
To say
$ grep -r "panic(" $GOROOT/src | wc -l
gave 3218 occurrences of explicit panic() call in stdlib. Really
impressive not panicking)
But design choice in reflect package intriguing me mostly.
Would be much appreciated for hints.
--
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/a8c61abf-a236-47d9-99a4-ad907412f427n%40googlegroups.com.
