Reconsider exception-handlers

Currently, Javalin will only run the closest matching exception handler. From the docs:

app.exception(NullPointerException.class, (e, ctx) -> {
    // handle nullpointers here
});

app.exception(Exception.class, (e, ctx) -> {
    // handle general exceptions here
    // will not trigger if more specific exception-mapper found
});

This could be a bit annoying to deal with, especially when developing plugins (as pointed out by @jkschneider in https://github.com/tipsy/javalin/pull/959)

Should multiple exception handlers be allowed to run per exception?

Should we have something like next()/done() ?

This would be a breaking change, but I guess we could also make it configurable.

[MrThreepwood]

For the projects we’ve done we’ve always handled multiple expected exceptions that parse the exception into a specific response and status, and one that is a fall back in case no better exception would be handled (which turns into a 500, sorry something went wrong).

It seems reasonable to think most of these handlers would be handled separately, I would have been very surprised if multiple handlers were called when a specific exception (like Unauthorized) was called. Especially if some of those were expensive. The way I’ve been looking at the exception handlers are: An exception ocurred, decide what response should be sent to the client. It doesn’t really make sense to ask multiple functions what response should be provided, but maybe I’m thinking about them differently than others do?

Maybe it would be easier to have a separate function for registering handlers that should run on all exceptions? Something like app.notifyOnException(Exception.class, (e, ctx) ->{})?

[jkschneider]

I also think that ideally things bound with the current exception() should probably be called after anything bound with this new method?

There are probably cases to suggest this should work both ways. From my perspective as a metrics instrumentation library author, I would prefer listeners to be called after anything that currently implements exception(..). Specifically, this is because my listener would be completing a timing operation on a REST endpoint, and I want to be able to tag this telemetry with the HTTP status code, which can be influenced by a traditional exception handler.