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
{{ message }}
This repository has been archived by the owner on Mar 11, 2020. It is now read-only.
This is perhaps due to the threaded/asynchronous nature of the journal library, but fatal exceptions are not logged unless they are handled specially. This issue may be more one of documentation, as a workaround exists, but it may be worth investigating whether it would be possible to deal with the problem so the workaround was not necessary.
No log file is written, perhaps because the application terminates (along with the logger threads) before any buffers are flushed and a message is written.
Conversely, you can ensure that the exception will be logged with:
Note the direct call to log.backend in the catch block. This appears to bypass the threading, ensuring the message reaches the log before the application terminates. I think this is mostly a reasonable workaround, so long as your application is sufficiently simple to have just one or two places where this specialized try/catch/log behavior is necessary, but it might merit a note in the documentation.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
This is perhaps due to the threaded/asynchronous nature of the journal library, but fatal exceptions are not logged unless they are handled specially. This issue may be more one of documentation, as a workaround exists, but it may be worth investigating whether it would be possible to deal with the problem so the workaround was not necessary.
To reproduce this issue with 2.2.1, run:
No log file is written, perhaps because the application terminates (along with the logger threads) before any buffers are flushed and a message is written.
Conversely, you can ensure that the exception will be logged with:
Note the direct call to
log.backend
in thecatch
block. This appears to bypass the threading, ensuring the message reaches the log before the application terminates. I think this is mostly a reasonable workaround, so long as your application is sufficiently simple to have just one or two places where this specializedtry
/catch
/log
behavior is necessary, but it might merit a note in the documentation.The text was updated successfully, but these errors were encountered: