New submission from Ryan Leslie <ryle...@gmail.com>: When using the logging package, if a StreamHandler is configured with stderr and stderr is redirected to a pipe which no longer has readers, then StreamHandler.emit() will result in an IOError for "Broken pipe". The exception will be handled in logging.Handler.handleError(), which by default will call traceback.print_exception() with file=sys.stderr. This will cause in a second IOError exception which will not be caught within the logging code. Unless the user placed their log calls such as logging.info() in a try/except block (unlikely), the end result is termination of the process.
While the logging code itself is certainly not the cause of the underlying problem, it does seem that the intent of the default handleError() was to eat exceptions, and possibly print them, without disturbing the application code. As the docstring correctly points out, the application can probably survive without the logging. To work around this issue without writing a custom handler, raiseExceptions can be set to false. But then the user would miss log trace when other types of errors not affecting stderr occurred. That is, I think handleError() does the right thing in trying to print the error, but suggest that if the print results in an IOError (or certain types of IOError), then it should be ignored, or optionally ignorable. ---------- components: Library (Lib) messages: 87469 nosy: ryles severity: normal status: open title: logging.Handler.handlerError() may raise IOError in traceback.print_exception() type: behavior versions: Python 2.6 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue5971> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
