Skip to main content
Every error that alterself raises derives from a single base class, AlterselfError, so you can always write a broad catch at the top of your stack and narrow it down as needed. Understanding the exception hierarchy lets you write targeted handlers that recover gracefully from transient failures, surface useful diagnostics for permanent ones, and avoid silently swallowing errors that require your attention.

Exception Hierarchy


HTTPError

HTTPError is raised whenever Discord’s REST API responds with a 4xx or 5xx status code. The exception exposes the raw HTTP status, Discord’s internal error code, and the human-readable message from the response body.

Common Discord Error Codes

Check e.code (the Discord JSON error code) rather than e.status (the HTTP status) for precise branching. Many different error conditions all return 400 Bad Request but carry distinct code values.

SessionClosed

SessionClosed is raised when Discord closes the WebSocket connection with a non-resumable close code. alterself will not attempt to reconnect automatically when this exception is raised, because most fatal close codes indicate a configuration problem rather than a transient network hiccup.

Fatal Gateway Close Codes

Close code 4004 means your token is invalid or has been invalidated (e.g. password changed, token reset). This is unrecoverable, so no amount of reconnection will help. Check your token immediately and update it before restarting the bot.

CaptchaChallenge

When Discord decides it needs human verification for an action (usually account-sensitive HTTP requests), it responds with a captcha challenge rather than the expected data. alterself surfaces this as a CaptchaChallenge exception instead of silently failing.
The two key attributes are: Pass both to your chosen captcha-solving service, retrieve the solution token, then retry the request with captcha_key=<token> in the request body.

CommandError and its Subclasses

CommandError and its subclasses are raised inside the command dispatch pipeline. You handle them by registering an on_command_error event listener.

CheckFailed

CheckFailed is raised when a @bot.check or @command.check decorator returns a falsy value. By default, alterself silently drops the invocation, so the command simply does not run and no error message is sent. If you want to notify the user, handle it explicitly in on_command_error:
CheckFailed is intentionally silent by default. This keeps your selfbot from drawing attention when commands are triggered by other users who don’t meet your access requirements.

Global Error Handler

For a production selfbot, register a single on_command_error handler that covers every CommandError subclass and logs everything else: