Exception handling does not (easily) support returning custom error views for non-API endpoints

[davidbyoung]

Our exception handlers are especially configured to create responses for API calls. However, this makes it difficult (impossible?) to reuse the API library for returning server-side rendered views.

Possible options to explore:

• Registering AJAX response factories and non-AJAX response factories

[davidbyoung]

Thoughts

I can separate out registering a global exception handler from a handler that returns an HTTP response. The former would use set_error_handler() and the latter would require adding the following classes:

• GlobalExceptionHandler - Used for handling exceptions that got passed our exception handler middleware. Because this can occur before the request has been created, it would not have a current request for context. It would return a default exception response that could be customized via a lambda expression.
• ExceptionHandler - Middleware that uses the current request for context to create an exception response
• ExceptionLogger - The logger that can take an exception in and determine what log level that exception has

[davidbyoung]

I've rewritten exception handling to have two distinct components:

• Handling an exception thrown in the middleware pipeline via ExceptionHandler
• Handling otherwise unhandled exceptions via GlobalExceptionHandler

I still need to settle on whether or not I want to move the registerFactory() and registerManyFactories() methods from ExceptionResponseFactoryRegistry to ExceptionResponseFactory (perhaps they could be methods only available on the concrete implementation of IExceptionResponseFactory). It feels a little overkill to have the factory compose the registry. I'll have to mull this over.

[davidbyoung]

This also brings up the question of whether or not exception handling should go in its own library, dependent on Net and Middleware. It's not inherently tied up with API anymore.