Closed magnet closed 7 years ago
Hi,
I think it would be a nice addition to wisdom-filters.
Having both a filter and an interceptor would be nice. The filter, as you said may have the wrong stack, but enough information to be usable.
The interceptor can be really useful too when you have actions that "don't want to obey to your will"
Currently throwables that are not caught in user-code are converted through a result (directly if it's an HttpException, or using an ExceptionMapper) but no logging is done.
It's really practical to log these exceptions to fix bugs that might not be reported by users, or incompletely.
Rather than adding logging in the engine, it would be nice to have a filter that just runs
(a smarter implementation would use ExceptionMappers to check if this exception has a status representing an error, e.g in the 500's).
However, I'm not sure how it would articulate with the Async interceptor: it has to filter BETWEEN Async and the downstream filters/actual controller, otherwise the exception will not unwind in the right stack. An other possibility is to make it an interceptor, with a @LogExceptions annotation. While this is nice so we can decide which controllers/routes log, it still prevents us from making it a global parameter.
What do you think?