Question to all you Gophers out there: How do you deal with custom errors that include more information and different kinds of matching them?

I started with a simple var ErrPermissionNotAllowed = errors.New("permission not allowed"). In my function I then wrap that using fmt.Errorf("%w: %v", ErrPermissionNotAllowed, failedPermissions). I can match this error using errors.Is(err, ErrPermissionNotAllowed). So far so good.

Now for display purposes I’d also like to access the individual permissions that could not be assigned. Parsing the error message is obviously not an option. So I thought, I create a custom error type, e.g. type PermissionNotAllowedError []Permission and give it some func (e PermissionNotAllowedError) Error() string { return fmt.Sprintf("permission not allowed: %v", e) }. My function would then return this error instead: PermissionNotAllowedError{failedPermissions}

At some layers I don’t care about the exact permissions that failed, but at others I do, at least when accessing them. A custom func (e PermissionNotAllowedError) Is(target err) bool could match both the general ErrPermissionNotAllowed as well as the PermissionNotAllowedError. Same with As(…). For testing purposes the PermissionNotAllowedError would then also try to match the included permissions, so assertions in tests would work nicely. But having two different errors for different matching seems not very elegant at all.

Did you ever encounter this scenario before? How did you address this? Is my thinking flawed?

@lyse@lyse.isobeef.org This is exactly how I would approach it 👌

Why not just always use the second one?

Why not just always use the second one?

You can have Error return just “permission not allowed” if the array is empty. It would print the same as the first.

You can have Error return just “permission not allowed” if the array is empty. It would print the same as the first.

@lyse@lyse.isobeef.org do you need to have an explicit Is function? I believe errors.Is has reflect lite and can do the type infer for you. The Is is only really needed if you have a dynamic type. Or are matching a set of types as a single error maybe? The only required one would be Unwrap if your error contained some other base type so that Is/As can reach them in the stack.

As is perfect for your array type because it asserts the matching type out the wrap stack and populates the type for evaluating its contents.

@lyse@lyse.isobeef.org do you need to have an explicit Is function? I believe errors.Is has reflect lite and can do the type infer for you. The Is is only really needed if you have a dynamic type. Or are matching a set of types as a single error maybe? The only required one would be Unwrap if your error contained some other base type so that Is/As can reach them in the stack.

As is perfect for your array type because it asserts the matching type out the wrap stack and populates the type for evaluating its contents.

So you would have:

type ErrPermissionNotAllowed []Permission
func (perms ErrPermissionNotAllowed) Is(permission Permission) bool {
    for _, p := range perms {
        if p == permission { return true }
    }
    return false
}
var err error = errPermissionNotAllowed{"is-noob"}

if errors.Is(err, ErrPermissionNotAllowed{}) { ... } // user is not allowed

var e ErrPermissionNotAllowed
if errors.As(err, e) && e.Is("a-noob") { ... } // user is not allowed because they are a noob. 

So you would have:

type ErrPermissionNotAllowed []Permission
func (perms ErrPermissionNotAllowed) Is(permission Permission) bool {
    for _, p := range perms {
        if p == permission { return true }
    }
    return false
}
var err error = errPermissionNotAllowed{"is-noob"}

if errors.Is(err, ErrPermissionNotAllowed{}) { ... } // user is not allowed

var e ErrPermissionNotAllowed
if errors.As(err, e) && e.Is("a-noob") { ... } // user is not allowed because they are a noob. 

I suppose to lesson confusion I would rename Is to Because

I suppose to lesson confusion I would rename Is to Because