3 ms·
What you're describing with net.Error is a sentinel error. var Error = errors.New("your error string") You can also create a type or a struct that implements
by zalmoxes 10y ago
What you're describing with net.Error is a sentinel error.
var Error = errors.New("your error string")
You can also create a type or a struct that implements error.
Example from stdlib:
```
// PathError records an error and the operation and file path that caused it.
type PathError struct {
Op string
Path string
Err error
}
func (e *PathError) Error() string { return e.Op + " " + e.Path + ": " + e.Err.Error() }
```
Dave Cheney's other blog post/talk goes into various ways to handle errors in Go here:
http://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully http://dave.cheney.net/2016/04/27/dont-just-check-errors-han...
- fauigerzigerk 10y agoI know all the options I have and I have read everything Dave Cheney (and Rob Pike) has written on the subject. But to quote myself: "there is no way to add instance specific information to errors in a later version of a package". Once you have decided to use a package level error value (sentinel error as you say), there is no way to change that. As there is a huge number of such error values in the standard library and also a substantial number of other types of errors like PathError, "there is no general and reliable way to handle specific types of errors".
- uluyol 10y agoMethods can always be added. Yes the values and types can't be changed but we can extend the existing types to have these methods and give naked error values (errors.New) new types. It wouldn't be breaking the Go1 guarantee because they would still have the type error, only the underlying type would change.
- fauigerzigerk 10y agoAll true, I never said anything different. But what's the point of adding methods? What you can't do is add call specific information to errors returned from a particular function if that function returned a package level singleton value before.
- uluyol 10y agoI see. This isn't always true, many places in the standard library do not document what error they will return. Changing these wouldn't violate the Go1 guarantee either. I see that other people have made the argument in support of Dave Cheney's approach already so I won't repeat it.
- fauigerzigerk 10y agoIs there a commitment by the Go team to adopt Dave Cheney's approach for the standard library?
- zalmoxes 10y agoIf I'm understanding you correctly, your complaint is that the errors are part of your packages API, so there is no way to change the errors you return without making breaking changes to your API contract?
- fauigerzigerk 10y agoYes, that and the many different ways to check the type of errors.