Again, I have read Dave Cheney's posts, and I totally agree with his conclusion that sentinel errors (i.e. public package level singletons) should not be used. I don't necessarily agree with his stance on error types, because sometimes we need access to specific data attached to errors (e.g SQLSTATE).
But the standard library uses sentinel errors everywhere and third party packages often do the same. That's what creates the inconsistent and messy status quo of handling different types of errors. It's also not going to change because sentinel errors can never be changed into anything different without breaking clients of the API. No call specific message or other data will ever be added to these standard error values.
> sometimes we need access to specific data attached to errors (e.g SQLSTATE).
Dave's post and my entire comment directly address this: Add a `SQLCode() int` method to the custom error, return `error` type and users can assert `codeErr, ok := err.(interface{SQLCode() int}); code := codeErr.SQLCode();` somewhere up the stack to get it.
But yes, the standard library's use of sentinel errors is unfortunate and can't be fixed.
But the standard library uses sentinel errors everywhere and third party packages often do the same. That's what creates the inconsistent and messy status quo of handling different types of errors. It's also not going to change because sentinel errors can never be changed into anything different without breaking clients of the API. No call specific message or other data will ever be added to these standard error values.