Hi! Regarding MDC (with use of `withLoggingContext`). Is there considered any best practices for MDC...

# kotlin-logging

[John Kasper Svergja]

Hi! Regarding MDC (with use of withLoggingContext). Is there considered any best practices for MDC and exceptions?
The current implementation of withLoggingContext clears all MDC fields if an exception inside the flow occurs. I would very much like the exception to contain the MDC-information.
One solution could be that withLoggingContext provides an option to provided an exception handler. (I think it is important not to couple the exception handling to close to the framework).

Do you have any thoughts about this/what do you think? Or any suggestion on how the mdc is kept for exceptions?

For my case I think the best use of an exception handler would be to add an “meta”-exception to the original exception (addSuppressed method ) (which is what I have done in my code, by creating a wrapper method around withLoggingContext )

[Jakub Gwóźdź]

If (second approach) I understand your question correctly, you want to enrich the exception call with kind of ctx: Map<String, String> that is set with MDC.getCopyOfContextMap() when thrown? Is this your own exception class, or existing one?

[John Kasper Svergja]

Yes, that is correct. P.t. I am thinking a exception class of my own (MdcMetadataException, or something), but since I am thinking of using addSuppressed I guess the exception can be provided by the library

[John Kasper Svergja]

Example of what i have p.t. (the resulting exception object is shown in the evaluate dialog)

[oshai]

the idea to provide an exception handler as parameter makes sense. it just feels like we're starting to have more and more signatures, and maybe the best approach is to have an "object style" api (to keep the state of all parameters).