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
> <golang-nuts@googlegroups.com> 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 <uvelichi...@gmail.com> 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 20000 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.
