PR #2128 should be the solution here. But, I think it is only part of a greater solution needed.

[ahopkins]

1. You should not be able to register the same exception more than once, or at least not on the same App/Blueprint.
2. Handlers should only be fetched in relation to the BP or App context of the matched route. This effectively means that some exceptions (NotFound could only be registered app level).

Originally posted by @ahopkins in https://github.com/sanic-org/sanic/issues/2121#issuecomment-827077284

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is incorrect, please respond with an update. Thank you for your contributions.

[prryplatypus]

Hello!

Regarding point 2, there is currently useful usecases to register exceptions like NotFound at a BP level. For example, you may have an API blueprint where you want all responses to be returned as JSON; but want them to be returned as HTML everywhere else.

I believe currently it is possible to do this and, if I understand correctly, point 2 would remove the ability to do so.

[ahopkins]

I guess it could work if you manually raised NotFound. But if the route does not exist, there is no way for Sanic to know which blueprint (and therefore which handler) to apply.

[prryplatypus]

What if the blueprint has a URL prefix? I'd expect the blueprint's error handler to try handling any errors within that URL prefix, if no child handles them before. 🤔

[ahopkins]

That is not likely something we will introduce since it would require adding default routes to blueprint handlers as catch-all. Which would and could have some bizarre unintended (and difficult to debug) consequences.

Since NotFound could be raised manually in legit use cases, maybe we need to identify some (like this and NoMethod) that should raise a warning on BP registration.

[AndreasPantle]

What if the blueprint has a URL prefix? I'd expect the blueprint's error handler to try handling any errors within that URL prefix, if no child handles them before. 🤔

This is exactly how I thought it should work.

There can be some use cases out there: Say, if you have a blueprint for a GUI serving and you like to do special stuff with Exceptions here in a (sub)URL.

[ahopkins]

If that's the case I'd suggest catching the exception with an exception handler and checking if the target path segment is in the current request path.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is incorrect, please respond with an update. Thank you for your contributions.

[ahopkins]

...

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is incorrect, please respond with an update. Thank you for your contributions.