Error Handling Patterns Every CLI Tool Needs

Error Handling Patterns Every CLI Tool Needs Error handling in CLI tools is fundamentally different from error handling in web applications. There's no retry button. No error boundary component. No loading spinner to buy time. When your CLI fails, the user sees a stack trace, a cryptic message, or nothing at all — and they lose trust in your tool. Good error handling in CLI tools means three things: the user understands what went wrong, they know how to fix it, and your CI pipeline gets the right exit code. Let's build all three. The Three Audiences for Errors Every CLI error serves three audiences simultaneously: The human in a terminal — needs a clear, actionable message The CI pipeline — needs a non-zero exit code The developer debugging — needs details when --verbose is on class CliError extends Error { constructor ( message , { code = 1 , suggestion , details } = {}) { super ( message ); this . code = code ; this . suggestion = suggestion ; this . details = details ; } } function