csnemes / tracer

Tracing rewriter using Fody
Apache License 2.0
93 stars 26 forks source link

Exception trace with different log level #103

Closed WebDucer closed 10 months ago

WebDucer commented 3 years ago

In most cases the trace log is not on by default, but we want to know, if an unexpected exception was thrown. So it would help to trace "only" the exceptions. This could be done, if e.g. the log of exception would use "Info" or "Warn" level (or configurable), instead of the "Trace" level, as for entry and exit.

In the logger we then can activate this level by default.

csnemes commented 3 years ago

The reason for logging exception as a trace is that it gets logged as the "result" of the method call. So if an exception occurs deep in the application in gets logged as the return value of the methods in the call stack until it gets processed by an exception handler. It would probably make sense to log the first occurrence of the exception as info/warn and the rest still can be trace. Or all exceptions should go to trace, even if its just a repetition? What's your take on it?

WebDucer commented 3 years ago

I think, it make sense to log not only the first occurrence of exception. It would need less change on the current tracer.

My intention is to be able to log unexpected exception as INFO/WARN (that we probably overlooked during development) and have the possibility to turn TRACE on, if we try to reproduce the error. Permanently turn TRACE on produce too much data and lower application performance.

Sometimes we get exceptions from external components / controls (Xamrin.Forms) that we not expect. We don't want to decorate all methods with try/catch manually to track this errors.

E.g. we have an MVVM Command with Execute and CanExecute methods in ViewModels. The Commands are triggered by UI components. We see in log only, that the error happen in the Command binding property. So in our error log we don't see which of the ViewModels is involved.