question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Cannot define a blueprint-specific exception handler

See original GitHub issue

Describe the bug The documentation at https://sanicframework.org/en/guide/best-practices/blueprints.html#exceptions says that:

Just like other exception handling, you can define blueprint specific handlers.

However, exception handlers defined this way don’t seem to be blueprint-specific at all. Instead, they handle exceptions in other blueprints as well.

Code snippet

#!/usr/bin/env python3

from sanic import Sanic, Blueprint, response

class Error(Exception):
    pass

handled = Blueprint("handled")
@handled.exception(Error)
def handle_error(req, e):
    return response.text("handled {}".format(e))

b = Blueprint("b")
@b.route("/")
def e(request):
    raise Error("error in e")

app = Sanic(__name__)
app.blueprint(handled)
app.blueprint(b)
app.run()

Expected behavior A request to http://localhost:8000 should generate 500, because Error should not be handled. Instead, the request generates 200, Error is handled, even though the handler is registered in handled, while the endpoint is in b.

Environment (please complete the following information):

  • OS: ubuntu 19.10
  • Version: Sanic 21.6.0; Routing 0.7.0

Additional context The order of blueprint registration does not seem to change anything. Not registering blueprint handled obviously fixes the issue.

Is it a bug or am I missing something here?

Issue Analytics

  • State:closed
  • Created 2 years ago
  • Reactions:1
  • Comments:5 (3 by maintainers)

github_iconTop GitHub Comments

1reaction
ahopkinscommented, Sep 27, 2021

See #2246 with a fix to this.

1reaction
komar007commented, Sep 27, 2021

Thanks,

it works as expected.

The code from the OP is indeed not a sensible use case, just the simplest reproduction path.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Unexpected behavior using a catch-all Blueprint exception ...
Describe the bug Using a catch-all exception handler in a Blueprint might lead to unexpected behavior. For example: from sanic import Sanic, ...
Read more >
flask - errorhandler in separate blueprint is not working
Whenever I am encountering an error, I am raising it using abort, for example abort(404). I created a new blueprint for error handling,...
Read more >
Handling Application Errors — Flask Documentation (2.2.x)
These error handlers are only invoked from an appropriate raise statement or a call to abort in another of the blueprint's view functions;...
Read more >
Troubleshooting blueprint errors in AWS Glue
If you encounter errors when using AWS Glue blueprints, use the following solutions to help you find the source of the problems and...
Read more >
Exceptions | Sanic Framework
request("/", error_format="text") async def handler(request): ... Copied! # Custom error handling. In some cases, you ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found