Currently, when RequestFilterHandler executes RequestAndResponseFilters, any exceptions thrown by the filter are logged with an error-level log message saying filters should never throw exceptions and the exception is then ignored.
This decision was made under the assumption that bad filters shouldn't cause your application to stop functioning, however this prevents filters from triggering the riposte error handling logic to take advantage of the common error contract and error handling behaviors. There are some use cases where this would be desirable.
Some solution should be implemented to allow filters to intentionally trigger error handling. Maybe a default boolean shouldSwallowExceptions() method on RequestAndResponseFilter that lets you choose on a per-filter basis whether thrown exceptions should be swallowed or allowed to trigger error handling? Or maybe a more flexible default boolean shouldSwallowException(Throwable t) where you can choose to swallow some errors and trigger error handling with others? We might also want to reconsider the default behavior and switch to having filters trigger error handling by default, and require filters to override the method if they want the swallow behavior instead. Hard to know which is the more common use case.
Currently, when
RequestFilterHandlerexecutesRequestAndResponseFilters, any exceptions thrown by the filter are logged with an error-level log message saying filters should never throw exceptions and the exception is then ignored.This decision was made under the assumption that bad filters shouldn't cause your application to stop functioning, however this prevents filters from triggering the riposte error handling logic to take advantage of the common error contract and error handling behaviors. There are some use cases where this would be desirable.
Some solution should be implemented to allow filters to intentionally trigger error handling. Maybe a
default boolean shouldSwallowExceptions()method onRequestAndResponseFilterthat lets you choose on a per-filter basis whether thrown exceptions should be swallowed or allowed to trigger error handling? Or maybe a more flexibledefault boolean shouldSwallowException(Throwable t)where you can choose to swallow some errors and trigger error handling with others? We might also want to reconsider the default behavior and switch to having filters trigger error handling by default, and require filters to override the method if they want the swallow behavior instead. Hard to know which is the more common use case.