Exceptions

Using Sanic exceptions#

Sometimes you just need to tell Sanic to halt execution of a handler and send back a status code response. You can raise a SanicException for this and Sanic will do the rest for you.

You can pass an optional status_code argument. By default, a SanicException will return an internal server error 500 response.

from sanic.exceptions import SanicException

@app.route("/youshallnotpass")
async def no_no(request):
        raise SanicException("Something went wrong.", status_code=501)

Sanic provides a number of standard exceptions. They each automatically will raise the appropriate HTTP status code in your response. Check the API reference for more details.

from sanic import exceptions

@app.route("/login")
async def login(request):
    user = await some_login_func(request)
    if not user:
        raise exceptions.NotFound(
            f"Could not find user with username={request.json.username}"
        )

Exception properties#

All exceptions in Sanic derive from SanicException. That class has a few properties on it that assist the developer in consistently reporting their exceptions across an application.

• message
• status_code
• quiet
• headers
• context
• extra

All of these properties can be passed to the exception when it is created, but the first three can also be used as class variables as we will see.

class CustomError(SanicException):
    message = "Something bad happened"

raise CustomError
# or
raise CustomError("Override the default message with something else")

class TeapotError(SanicException):
    status_code = 418
    message = "Sorry, I cannot brew coffee"

raise TeapotError
# or
raise TeapotError(status_code=400)

class SilentError(SanicException):
    message = "Something happened, but not shown in logs"
    quiet = True

raise SilentError
# or
raise InvalidUsage("blah blah", quiet=True)

app.config.NOISY_EXCEPTIONS = True

class MyException(SanicException):
    headers = {
      "X-Foo": "bar"
    }

raise MyException
# or
raise InvalidUsage("blah blah", headers={
    "X-Foo": "bar"
})

raise SanicException(..., extra={"name": "Adam"})

raise SanicException(..., context={"foo": "bar"})

Handling#

Sanic handles exceptions automatically by rendering an error page, so in many cases you don't need to handle them yourself. However, if you would like more control on what to do when an exception is raised, you can implement a handler yourself.

Sanic provides a decorator for this, which applies to not only the Sanic standard exceptions, but any exception that your application might throw.

from sanic.exceptions import NotFound

@app.exception(NotFound, SomeCustomException)
async def ignore_404s(request, exception):
    return text("Yep, I totally found the page: {}".format(request.url))

@app.exception(Exception)
async def catch_anything(request, exception):
    ...

async def server_error_handler(request, exception):
    return text("Oops, server error", status=500)

app.error_handler.add(Exception, server_error_handler)

Built-in error handling#

Sanic ships with three formats for exceptions: HTML, JSON, and text. You can see examples of them below in the Fallback handler section.

@app.request("/", error_format="text")
async def handler(request):
    ...

Custom error handling#

In some cases, you might want to add some more error handling functionality to what is provided by default. In that case, you can subclass Sanic's default error handler as such:

from sanic.handlers import ErrorHandler

class CustomErrorHandler(ErrorHandler):
    def default(self, request: Request, exception: Exception) -> HTTPResponse:
        ''' handles errors that have no error handlers assigned '''
        # You custom error handling logic...
        status_code = getattr(exception, "status_code", 500)
        return json({
          "error": str(exception),
          "foo": "bar"
        }, status=status_code)

app.error_handler = CustomErrorHandler()

Fallback handler#

Sanic comes with three fallback exception handlers:

1. HTML
2. Text
3. JSON

These handlers present differing levels of detail depending upon whether your application is in debug mode or not.

By default, Sanic will be in "auto" mode, which means that it will using the incoming request and potential matching handler to choose the appropriate response format. For example, when in a browser it should always provide an HTML error page. When using curl, you might see JSON or plain text.

HTML#

app.config.FALLBACK_ERROR_FORMAT = "html"

app.config.DEBUG = True

app.config.DEBUG = False

Text#

app.config.FALLBACK_ERROR_FORMAT = "text"

app.config.DEBUG = True

curl localhost:8000/exc -i
HTTP/1.1 500 Internal Server Error
content-length: 620
connection: keep-alive
content-type: text/plain; charset=utf-8

⚠️ 500 — Internal Server Error
==============================
That time when that thing broke that other thing? That happened.

ServerError: That time when that thing broke that other thing? That happened. while handling path /exc
Traceback of TestApp (most recent call last):

  ServerError: That time when that thing broke that other thing? That happened.
    File /path/to/sanic/app.py, line 979, in handle_request
    response = await response

    File /path/to/server.py, line 16, in handler
    do_something(cause_error=True)

    File /path/to/something.py, line 9, in do_something
    raise ServerError(

app.config.DEBUG = False

curl localhost:8000/exc -i
HTTP/1.1 500 Internal Server Error
content-length: 134
connection: keep-alive
content-type: text/plain; charset=utf-8

⚠️ 500 — Internal Server Error
==============================
That time when that thing broke that other thing? That happened.

JSON#

app.config.FALLBACK_ERROR_FORMAT = "json"

app.config.DEBUG = True

curl localhost:8000/exc -i
HTTP/1.1 500 Internal Server Error
content-length: 572
connection: keep-alive
content-type: application/jso

{
  "description": "Internal Server Error",
  "status": 500,
  "message": "That time when that thing broke that other thing? That happened.",
  "path": "/exc",
  "args": {},
  "exceptions": [
    {
      "type": "ServerError",
      "exception": "That time when that thing broke that other thing? That happened.",
      "frames": [
        {
          "file": "/path/to/sanic/app.py",
          "line": 979,
          "name": "handle_request",
          "src": "response = await response"
        },
        {
          "file": "/path/to/server.py",
          "line": 16,
          "name": "handler",
          "src": "do_something(cause_error=True)"
        },
        {
          "file": "/path/to/something.py",
          "line": 9,
          "name": "do_something",
          "src": "raise ServerError("
        }
      ]
    }
  ]
}

app.config.DEBUG = False

curl localhost:8000/exc -i
HTTP/1.1 500 Internal Server Error
content-length: 129
connection: keep-alive
content-type: application/json

{
  "description": "Internal Server Error",
  "status": 500,
  "message": "That time when that thing broke that other thing? That happened."
}

Auto#

Sanic also provides an option for guessing which fallback option to use.

app.config.FALLBACK_ERROR_FORMAT = "auto"

Contextual Exceptions#

Default exception messages that simplify the ability to consistently raise exceptions throughout your application.

class TeapotError(SanicException):
    status_code = 418
    message = "Sorry, I cannot brew coffee"

raise TeapotError

But this lacks two things:

1. A dynamic and predictable message format
2. The ability to add additional context to an error message (more on this in a moment)

Added in v21.12

Using one of Sanic's exceptions, you have two options to provide additional details at runtime:

raise TeapotError(extra={"foo": "bar"}, context={"foo": "bar"})

What's the difference and when should you decide to use each?

• extra - The object itself will never be sent to a production client. It is meant for internal use only. What could it be used for?
  • Generating (as we will see in a minute) a dynamic error message
  • Providing runtime details to a logger
  • Debug information (when in development mode, it is rendered)
• context - This object is always sent to production clients. It is generally meant to be used to send additional details about the context of what happened. What could it be used for?
  • Providing alternative values on a BadRequest validation issue
  • Responding with helpful details for your customers to open a support ticket
  • Displaying state information like current logged in user info

Dynamic and predictable message using extra#

Sanic exceptions can be raised using extra keyword arguments to provide additional information to a raised exception instance.

class TeapotError(SanicException):
    status_code = 418

    @property
    def message(self):
        return f"Sorry {self.extra['name']}, I cannot make you coffee"

raise TeapotError(extra={"name": "Adam"})

The new feature allows the passing of extra meta to the exception instance, which can be particularly useful as in the above example to pass dynamic data into the message text. This extra info object will be suppressed when in PRODUCTION mode, but displayed in DEVELOPMENT mode.

Additional context to an error message#

Sanic exceptions can also be raised with a context argument to pass intended information along to the user about what happened. This is particularly useful when creating microservices or an API intended to pass error messages in JSON format. In this use case, we want to have some context around the exception beyond just a parseable error message to return details to the client.

raise TeapotError(context={"foo": "bar"})

This is information that we want to always be passed in the error (when it is available). Here is what it should look like:

{
  "description": "I'm a teapot",
  "status": 418,
  "message": "Sorry Adam, I cannot make you coffee",
  "context": {
    "foo": "bar"
  }
}

{
  "description": "I'm a teapot",
  "status": 418,
  "message": "Sorry Adam, I cannot make you coffee",
  "context": {
    "foo": "bar"
  },
  "path": "/",
  "args": {},
  "exceptions": [
    {
      "type": "TeapotError",
      "exception": "Sorry Adam, I cannot make you coffee",
      "frames": [
        {
          "file": "handle_request",
          "line": 83,
          "name": "handle_request",
          "src": ""
        },
        {
          "file": "/tmp/p.py",
          "line": 17,
          "name": "handler",
          "src": "raise TeapotError("
        }
      ]
    }
  ]
}

Error reporting#

Sanic has a signal that allows you to hook into the exception reporting process. This is useful if you want to send exception information to a third party service like Sentry or Rollbar. This can be conveniently accomplished by attaching an error reporting handler as show below:

@app.report_exception
async def catch_any_exception(app: Sanic, exception: Exception):
print("Caught exception:", exception)

Added in v23.6