Closed willfaught closed 1 year ago
Do you think there is a case to make it just a error
to avoid knowing the concrete struct?
If it's just an error
then the various errors should be exported for comparisons.
William Kennedy has a good blog post on error handling in Go.
It sounds like you do want to use pointers for custom Errors so that comparisons are of the memory address, not of a string representation.
If we returned an error
, the typical usage of it is if err != nil
to check the error and the type switch on the error to get the concrete struct type
Most things return error
because most of the time people don't care what it is and they just pass it on.
In this case, people are supposed to act on the error info immediately (if I understand correctly). Making the type error
would just cause a lot of code like nr.Err.(apns.Error).Identifier
.
I would advocate returning a pointer to the concrete type. Has:
but seems to mostly be used as a value. E.g. NotificationResult.Err is an Error, not an *Error.