Sys.excepthook is missing: Difference between revisions

From Helpful
Jump to navigation Jump to search
mNo edit summary
mNo edit summary
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{stub}}


An error like:
An error like:
Line 22: Line 20:




So if both of those were already cleaned up by something that caused an interpreter shutdown, you either
So if we're shutting down the interpreter, and ''both'' of those were already cleaned up, that's a thing.
 
If you're not the programmer, this is just a "program tried to print something while we were almost done stopping the process" and you don't need to chare.
 
If you are the programmer and you ''do'' care about showing that error, you either
: care about seeing this error a bunch ''earlier''  {{comment|(often means restructuring how/where you catch errors)}}
: care about seeing this error a bunch ''earlier''  {{comment|(often means restructuring how/where you catch errors)}}
: don't care about this error at all                {{comment|(often means you want to swallow the exception)}}
: don't care about this error at all                {{comment|(often means you want to swallow the exception)}}




If it's the latter, then the basic patchup is to swallow that specific case in a try-except.
 
If you want it to not shot that error, then one patchup is to swallow that specific case in a try-except.
:: In py2, that's a socket.error with errno==errno.EPIPE  (socket.error inherits from IOError, but only since py2.6)
:: In py2, that's a socket.error with errno==errno.EPIPE  (socket.error inherits from IOError, but only since py2.6)
:: In py3, that that's a BrokenPipeError
:: In py3, that that's a BrokenPipeError

Latest revision as of 14:49, 19 April 2024

An error like:

close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr


tl;dr:

  • it's trying to report an exception through a file object
  • ...where that's gone
    • usually because the program is in the middle of being shut down
    • or caused by a broken pipe (incoming SIGPIPE, Errno 32). Consider what a Ctrl-C does.


Roughly, python's exception handling seems to be

use sys.excepthook
if missing, write exception and traceback to sys.stderr


So if we're shutting down the interpreter, and both of those were already cleaned up, that's a thing.

If you're not the programmer, this is just a "program tried to print something while we were almost done stopping the process" and you don't need to chare.

If you are the programmer and you do care about showing that error, you either

care about seeing this error a bunch earlier (often means restructuring how/where you catch errors)
don't care about this error at all (often means you want to swallow the exception)


If you want it to not shot that error, then one patchup is to swallow that specific case in a try-except.

In py2, that's a socket.error with errno==errno.EPIPE (socket.error inherits from IOError, but only since py2.6)
In py3, that that's a BrokenPipeError
(to account for both, you may want something like:
try:
   bperror = BrokenPipeError
except NameError:
   bperror = socket.error

try:
    #your main code
except bperror:
    pass