feat: FromError unwraps based on an interface so it works with *exec.ExitError as well
#95
Conversation
|
Oh that's cool! I actually had no idea that |
| if errors.As(err, &e) { | ||
| return e.Code | ||
| return e.ExitCode() |
There was a problem hiding this comment.
Can't tell why is this better? Is it to capture anything that might not be derived from Error but can implement ExitCode()?
Also should the variable Code be not exported out, given you have the function ExitCode introduced below?
There was a problem hiding this comment.
Can't tell why is this better?
This is based on @alecthomas's feedback here — that instead of unwrapping based on type, it'd be better to unwrap based on interface, which totally makes sense.
Also should the variable
Codebe not exported out, given you have the functionExitCodeintroduced below?
I don't have a strong opinion on that; but the rest of this change should be nonbreaking for anything that uses square/exit, while renaming Code to code could be breaking.
| } else if err == nil { | ||
| return OK | ||
| } else { | ||
| return NotOK | ||
| } | ||
| } | ||
|
|
||
| func WrapIf(err error, code Code) error { |
There was a problem hiding this comment.
Not in this library!
but I've found myself writing the following a lot of times:
err := someFunctionThatParsesOrValidatesUserInput()
if err != nil {
err = exit.Wrap(err, exit.UsageError)
}and I'd rather be more declarative and say "errors returned by this function are a certain class of error" — more like this:
err := exit.WrapIf(someFunctionThatParsesOrValidatesUserInput(), exit.UsageError)
And can fall through to Kong based on alecthomas/kong#507