ChrisHines/go2errorsFeedback.md

## go2errorsFeedback.md

      
    Raw
  

              go2errorsFeedback.md
            
          
    The draft design defines a new errors.Formatter interface as follows.
package errors

// A Formatter formats error messages.
type Formatter interface {
	// Format is implemented by errors to print a single error message.
	// It should return the next error in the error chain, if any.
	Format(p Printer) (next error)
}
Unfortunately the choice of Format for the method name conflicts with method
defined by the fmt.Formatter interface by using the same method name with a
different signature. Existing error packages such as github.com/pkg/errors
define error types that already implement fmt.Formatter that would need to
change in a backwards incompatible way in order to participate in the suggested
error formatting paradigm.
Another example is the package github.com/go-stack/stack. It introduced the idea
of implementing fmt.Formatter for controlling the level of detail when printing
stack information. It also directly inspired that idea for errors in github.com/pkg/errors.
It would make sense for package github.com/go-stack/stack to implement errors.Formatter
alongside fmt.Formatter so that it could be used as a helper for custom error types. Package
github.com/go-stack/stack has other uses outside of error reporting that would likely
want to continue using the fmt.Formatter implementation.
I suggest changing the errors.Formatter interface to the following to avoid the conflict described above.
package errors

// A Formatter formats error messages.
type Formatter interface {
	// FormatError is implemented by errors to print a single error message.
	// It should return the next error in the error chain, if any.
	FormatError(p Printer) (next error)
}