4 ms·
In this example, you have to magically know that DB returns a statusError{} in order not to wrap it again. I've found one improvement is to encode this knowled
by mappu 3y ago
In this example, you have to magically know that DB returns a statusError{} in order not to wrap it again.
I've found one improvement is to encode this knowledge in the type system, by not using plain error returns on the handler, but instead use something like e.g.
type netError interface {
Error() string
Public() bool
StatusCode() int
Unwrap() error
}
func PublicError(e error, code int) netError { ... }
func InternalError(e error) netError { ... }
func SomeHandler(h *http.Request, w http.ReponseWriter) netError { ... }
This makes it clearer whether the underlying err "knows" if it should be public or private.
- earthboundkid 3y agoThis seems like a good idea, but it will break lots of things. In particular, err != nil will break. Don’t do it.
- mappu 3y agoerr != nil works fine, exactly the same way it works for plain error: interface values can be nil,
- earthboundkid 3y agoWith this err will never equal nil.
- deleted 3y ago[deleted]
- binary132 3y agoReturning interfaces is an antipattern masquerading as a design pattern... Just saying