Error implements error with a pointer receiver

[willfaught]

but seems to mostly be used as a value. E.g. NotificationResult.Err is an Error, not an *Error.

[bdotdub]

Do you think there is a case to make it just a error to avoid knowing the concrete struct?

[nathany]

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.

[bdotdub]

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

[willfaught]

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.

[taylortrimble]

I would advocate returning a pointer to the concrete type. Has:

• Comparison advantage
• Can be checked for nil
• Can get detailed error info without type assertion