> I was referring to this errors.Wrap function [...] is this function deprecated/removed?
Got it. As the github.com identifier implies, that is a third-party library.
I suppose you could argue that said library is focused on strings, but then you could write a similar library in any language. Would you say that would also make those languages focused on strings? Probably not.
I don't think anyone would recommend that you use said library.
> you're required to have a string to create an error of course
It is true that said function does exist in the errors package (the standard library one), but is for defining error 'constants' meant to be evaluated on equality. Consider:
var MyError = errors.New("my error")
if (err == MyError) {
// We got MyError!
}
It is not the string that is significant. It is the comparable memory address that is significant.
Note: For reasons, you are bound to want to use errors.Is rather than == in this case, but the intent is the same. I choose to use == here as I think it explains it better.
> Rather than something more structured that's composed together, and then later (possibly) serialized to a string.
No, that's exactly what a Go error is. They are fully-fledged types, able to pack any kind of data you want in them. Consider:
type MyError struct {
Code int
User User
// ...
}
// Error is needed to satisfy the error interface.
func (m MyError) Error() string {
return fmt.Sprintf("code %d caused by %s", m.Code, m.User.Name)
}
func doSomething(user User) error {
return MyError{Code: 1, User: user}
}
That's an error in Go. You are right about strings to the extent that serialization to a string is a requirement of the error interface, but you don't ever need to use it. It is not significant to any meaningful degree. But as logging/reporting is a common way to deal with errors, it is understandable why the serialization is a requirement.
Of course, you don't have to use the error interface at all. Some functions in the Go standard library, as an example, use an int type to signify an error. You probably want to use `error` in the common case, though, so that your code plays nice with the expectations of others. Deviation should carry careful consideration.
Got it. As the github.com identifier implies, that is a third-party library.
I suppose you could argue that said library is focused on strings, but then you could write a similar library in any language. Would you say that would also make those languages focused on strings? Probably not.
I don't think anyone would recommend that you use said library.
> you're required to have a string to create an error of course
It is true that said function does exist in the errors package (the standard library one), but is for defining error 'constants' meant to be evaluated on equality. Consider:
It is not the string that is significant. It is the comparable memory address that is significant.Note: For reasons, you are bound to want to use errors.Is rather than == in this case, but the intent is the same. I choose to use == here as I think it explains it better.
> Rather than something more structured that's composed together, and then later (possibly) serialized to a string.
No, that's exactly what a Go error is. They are fully-fledged types, able to pack any kind of data you want in them. Consider:
That's an error in Go. You are right about strings to the extent that serialization to a string is a requirement of the error interface, but you don't ever need to use it. It is not significant to any meaningful degree. But as logging/reporting is a common way to deal with errors, it is understandable why the serialization is a requirement.Of course, you don't have to use the error interface at all. Some functions in the Go standard library, as an example, use an int type to signify an error. You probably want to use `error` in the common case, though, so that your code plays nice with the expectations of others. Deviation should carry careful consideration.