Clean way of sanitizing exceptions log messages

[rasmuscc]

Description

Currently, it's possible to filter log messages in Quarkus by creating a @LoggingFilter, which provides access to java.util.logging.LogRecord. However, I think there’s a limitation when it comes to sanitizing logged exception messages.

The issue is that while I can access the LogRecord's cause, it’s immutable. To sanitize exception messages, I think I'd need to iterate through the cause chain and create a new exception with an updated message for each cause which is cumbersome.

It would be beneficial to have a filter that directly applies to the final output written to the console. This would allow for easier sanitization of exception messages without needing to recreate the cause chain.

Implementation ideas

No response

[quarkus-bot[bot]]

/cc @dmlloyd (logging)

[dmlloyd]

We could approach this in two different ways:

• Create a "helper" method for use by filters which can reconstruct the exception graph while applying a filter function to each exception message
  • Pros:
    • The exception messages would be filtered for all loggers automatically
    • Other transformations could be applied too, like filtering stack trace elements
  • Cons:
    • Only "easy" if the throwables in question have the appropriate/expected constructor shape (no args, msg arg, cause arg, and msg+cause args); otherwise we have to resort to reflection or serialization to clone them
    • Difficult to apply to only a subset of handlers
    • Might make debugging difficult if the original exception is lost
• Augment the formatters with a way to customize exception formatting
  • Pros:
    • Aligned with what we're already doing in some cases e.g. reversing the causes list, adding in source code references to the stack frames, etc.
    • Should work for all throwable types
    • Can be customized on a per-handler basis
  • Cons:
    • Each handler's formatter would have to be set up with the filtered formatter somehow (our logging configuration and setup is a bit of a mess which might make it hard to do this cleanly)

[rasmuscc]

Which solution offers the best performance? Also, isn't it in theory possible for cycles to exist in the cause chain?

[dmlloyd]

I think the latter is likely to have the lowest run time overhead. And yes, cycles may exist in the causes chains but that isn't insurmountable.

[rasmuscc]

Thank you for the answer! I think the latter sounds like the "nicest" solution.