-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Additional logging for errors in ByteBufferAsyncProcessor #190
base: master
Are you sure you want to change the base?
Conversation
Since exceptions in this method may indicate a fatal error in the logging subsystem, the only place we're able to log them is LogLog.
myAllDataProcessed = false; | ||
Monitor.Pulse(myLock); | ||
LogLog.Error(ex); | ||
throw; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Note that rethrowing with “throw;” instead of “throw e;” would “preserve the corrupting-ness”, meaning the whole process would probably be torn down as the re-thrown exception continued to propagate.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hypersw suggests to use throw new Exception(e) to preserve the original callstack
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For this case, I don't think that's necessary.
Here, I want the following behavior from this code:
- If any exception (including the corrupted state one) is thrown, then the lock should be unlocked, and the exception should be logged without reentrancy into this code region, if possible (
LogLog
allows such logging). - If the caller of this code uses
[HandleProcessCorruptedStateExceptions]
, then let it to handle the exception as it wants to. - If the caller of this code doesn't use
[HandleProcessCorruptedStateExceptions]
, then fall back to the default behavior (say, crash the whole process).
My point is that the logger internals shouldn't modify the defaults chosen by the application domain policy or by the caller. I don't think that this code should care about transforming corrupted state exceptions into ordinary ones.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After an internal discussion, we've decided to make this behavior configurable.
Since exceptions in this method may indicate a fatal error in the logging subsystem, the only place we're able to log them is
LogLog
.