Custom error handler not called by `ServerErrorMiddleware` in debug mode

ServerErrorMiddleware ignores handler argument when app is running in debug mode. Instead, it always calls the default one.

from starlette.applications import Starlette
from starlette.responses import Response

def my_handler(request, exc): 
    if request.app.debug:
        return Response('Fail in debug mode')
    return Response('Fail in production mode')

app = Starlette(
    debug=True,
    exception_handlers={Exception: my_handler}
)

This causes us to do workarounds like reimplementing ServerErrorMiddleware on our own just to use an alternate exception handler in debug mode. Though intuitively, you expect exception_handlers for that purpose.

Would it make sense to always call a configured handler when available, and ignore the default one? A possible solution can look like this:

try:
    await self.app(scope, receive, _send)
except Exception as exc:
    request = Request(scope)
    if self.handler is not None:
        if is_async_callable(self.handler):
            response = await self.handler(request, exc)
        else:
            response = await run_in_threadpool(self.handler, request, exc)
    elif self.debug:
        # In debug mode, return traceback responses.
        response = self.debug_response(request, exc)
    else:
        # Use our default 500 error handler.
        response = self.error_response(request, exc)

Let me know if I can PR it.

[Kludex]

It doesn’t make sense to me for debug to lose priority. Like, usually you have your handlers, and to debug, you set the parameter.

Right, that was my rationale here too. For comparison, we’ve got equivalent behaviour here to Django’s 500 views and debug behaviour…

docs.djangoproject.com/en/4.0/ref/views/#the-500-server-error-view

Flask has the same behavior as well: https://flask.palletsprojects.com/en/2.2.x/errorhandling/#unhandled-exceptions

Why would Starlette do something different than those two?

[alex-oleshkevich]

@Kludex I think you can close it. However, I still believe that this is a good add-on to the library. The current implementation steals too much control from the developer.