Add ExceptionHandler type

[kristjanvalur]

In PR #2042 I pointed out problems with type checking of exception_handlers. Due to untyped handler functions in the unit tests, we didn't catch the fact that handlers were not conforming to the type hints after the support for handling WebSockets errors was added.

This PR aims to help this situation by introducing an ExceptionHandler class which wraps the handler function and provides proper type checking on the handler function. Unwrapped functions with the previous signature are still accepted as a fallback.

[adriangb]

I think this is what I would do if we were doing things from scratch and could accept a list[ExcHandler] in Starlette. But given that we can’t I think that an ExcHandlerBuilder(dict[Any, Any]) makes more sense.

I also think we don’t care about typing our internals for complex cases like this; anys is fine.

[kristjanvalur]

Well, it is always possible to introduce new keyword arguments without breaking backwards compatibility. it is really the exception_handlers dict which is problematic. It could be deprecated and replaced with something else. "error_handlers" for instance.

[kristjanvalur]

A separate ErrorHandler class would be useful too, because in addition to being able to specify the exception, it could also specify the type of the scope to which it applies. Currently that is not possible.

[Kludex]

I'm closing this given that we had a long discussion about it already: #1456.

[kristjanvalur]

Well, that discussion is closed too, and what remains is that the type of the exception_handlers is incorrect in the API and anyone trying to register exception handlers for websockets will be bitten by that. For a library which claims "100% type annotated codebase" that's not super.

Isn't it possible to build some consensus on how to move forward? Adding a new keyword for example which takes a list of exception handlers which are creted separately? I'll be happy to help.

Edit: Well, #2042 at contains an immediate fix to the api typing.