Hi! Regarding MDC (with use of `withLoggingContext...
# kotlin-logging
j
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
)
j
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?
j
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
Example of what i have p.t. (the resulting exception object is shown in the evaluate dialog)
o
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).
419 Views