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
> <https://groups.google.com/d/msgid/golang-nuts/a8c61abf-a236-47d9-99a4-ad907412f427n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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.
