You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Let's say some message fail to be logged (due to Exception raised during pickling or by the sink itself). If catch=False, the Exception will be re-raised, but it the user won't be able to catch it because it's raised from a internal thread. The error will be reported on sys.stderr by Python handler, but the thread will die, thus any all the subsequent logging messages will be discarded.
I think this behavior is not user-friendly and does have much interest. The catch=False makes sense to let user manage exception handling, which is not possible when enqueue=True anyway.
When enqueue=False and catch=False, the caller thread will die, but the sink will remain usable by others threads. The behavior should be the same when enqueue=True.
Also, it could simplify the code.
The text was updated successfully, but these errors were encountered:
Let's say some message fail to be logged (due to
Exception
raised during pickling or by the sink itself). Ifcatch=False
, theException
will be re-raised, but it the user won't be able to catch it because it's raised from a internal thread. The error will be reported onsys.stderr
by Python handler, but the thread will die, thus any all the subsequent logging messages will be discarded.I think this behavior is not user-friendly and does have much interest. The
catch=False
makes sense to let user manage exception handling, which is not possible whenenqueue=True
anyway.When
enqueue=False
andcatch=False
, the caller thread will die, but the sink will remain usable by others threads. The behavior should be the same whenenqueue=True
.Also, it could simplify the code.
The text was updated successfully, but these errors were encountered: