One more defense for GUI apps that call sys.excepthook. GUI frameworks like wxPython trap exceptions and call sys.excepthook themselves. I guess this is a feature that enables them to keep running after exceptions that would otherwise kill their mainloop. This is a
(self, etype, value, tb)
| 2088 | self.custom_exceptions = exc_tuple |
| 2089 | |
| 2090 | def excepthook(self, etype, value, tb): |
| 2091 | """One more defense for GUI apps that call sys.excepthook. |
| 2092 | |
| 2093 | GUI frameworks like wxPython trap exceptions and call |
| 2094 | sys.excepthook themselves. I guess this is a feature that |
| 2095 | enables them to keep running after exceptions that would |
| 2096 | otherwise kill their mainloop. This is a bother for IPython |
| 2097 | which expects to catch all of the program exceptions with a try: |
| 2098 | except: statement. |
| 2099 | |
| 2100 | Normally, IPython sets sys.excepthook to a CrashHandler instance, so if |
| 2101 | any app directly invokes sys.excepthook, it will look to the user like |
| 2102 | IPython crashed. In order to work around this, we can disable the |
| 2103 | CrashHandler and replace it with this excepthook instead, which prints a |
| 2104 | regular traceback using our InteractiveTB. In this fashion, apps which |
| 2105 | call sys.excepthook will generate a regular-looking exception from |
| 2106 | IPython, and the CrashHandler will only be triggered by real IPython |
| 2107 | crashes. |
| 2108 | |
| 2109 | This hook should be used sparingly, only in places which are not likely |
| 2110 | to be true IPython errors. |
| 2111 | """ |
| 2112 | self.showtraceback((etype, value, tb), tb_offset=0) |
| 2113 | |
| 2114 | def _get_exc_info(self, exc_tuple=None): |
| 2115 | """get exc_info from a given tuple, sys.exc_info() or sys.last_type etc. |
no test coverage detected