On 2/7/2014, 4:47 PM, Guido van Rossum wrote:
On Fri, Feb 7, 2014 at 1:37 PM, Yury Selivanov<[email protected]>wrote:
>
>On 2/7/2014, 3:52 PM, Guido van Rossum wrote:
>
>>Can't you add a reference to the loop to the tb logger object? The loop
>>should outlive any futures anyway (since the future has a reference to the
>>loop) and it shouldn't be a ref cycle.
>>
>> Sure.
>
>Another question: "logger.exception" is also used in:
>
>- selector_events.py: in _accept_connection, in case of errors in
>pause_writing/resume_writing and _fatal_error
>
>- proactor_events.py: in case of failed accept, _fatal_error and errors in
>pause/resume writing
>
>- unix_events.py: In pipe transport's _fatal_error, in case of exception
>in SIGCHLD handler
>
>- windows_events.py: pipe accept failed
>
>All of the above sites are logging exceptions (typically OSErrors). Should
>we use the loop exception API there, or you want to keep using loggers
>directly?
>
I've got a hunch saying that every place where we log an exception we
should use the new handler, but TBH I don't have much of a use case -- I've
been very happy with the default logging and I would probably just be
configuring the logger rather than overriding the exception handler.
I think it's time to ask Glyph for a use case that can't be dealt with by
overriding the logger.
I'm +1 on using the loop API everywhere. It just gives us more
control and flexibility in improving/working with error reporting
later down the road. Using logger directly feels inconsistent.
Yury
