Discussion on: Go 2 Draft: Error Values

[dean]

1: I'm saying it should be used instead of errors.Printer and errors.Formatter.

errors.Formatter is bad because this has more chance for programmer error. If the programmer forgets to print Error(), or return the next error, the purpose of Formatter has an extremely negative impact on anything trying to print it. It leaves for too much human error.

This doesn't violate SRP any more than errors.Formatter does. Either way, fmt, golang.org/x/text/message, etc. will each need to implement errors.Printer, where fmt.Print doesn't have the same function as p.Print. If we didn't want to violate SRP, we should be forced to implement fmt.Formatter rather than a special errors.Formatter.

Using Detailer instead of Formatter also allows for much more parsable errors. For instance, if I wanted JSON for my error, I can now very easily parse my error to:

{
    "error": /* err.Error() */
    "details": /* err.Details() (if implementing) */
    "wraps": /* err.Unwrap() (if implementing) */
}

To do this with Formatter, you would need to create a custom errors.Printer and assume what is error vs what is details, because it is not clear as to what's what.

2: Yeah, honestly the more I think about it, the more I think that it should just be a function that the developer creates for their own needs.

[northbear]

I seem that name of interfaceFormatter matches better to context of fmt module, than name Detailer. The name Detailer is better for errors module.