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)
| 1933 | self.custom_exceptions = exc_tuple |
| 1934 | |
| 1935 | def excepthook(self, etype, value, tb): |
| 1936 | """One more defense for GUI apps that call sys.excepthook. |
| 1937 | |
| 1938 | GUI frameworks like wxPython trap exceptions and call |
| 1939 | sys.excepthook themselves. I guess this is a feature that |
| 1940 | enables them to keep running after exceptions that would |
| 1941 | otherwise kill their mainloop. This is a bother for IPython |
| 1942 | which excepts to catch all of the program exceptions with a try: |
| 1943 | except: statement. |
| 1944 | |
| 1945 | Normally, IPython sets sys.excepthook to a CrashHandler instance, so if |
| 1946 | any app directly invokes sys.excepthook, it will look to the user like |
| 1947 | IPython crashed. In order to work around this, we can disable the |
| 1948 | CrashHandler and replace it with this excepthook instead, which prints a |
| 1949 | regular traceback using our InteractiveTB. In this fashion, apps which |
| 1950 | call sys.excepthook will generate a regular-looking exception from |
| 1951 | IPython, and the CrashHandler will only be triggered by real IPython |
| 1952 | crashes. |
| 1953 | |
| 1954 | This hook should be used sparingly, only in places which are not likely |
| 1955 | to be true IPython errors. |
| 1956 | """ |
| 1957 | self.showtraceback((etype, value, tb), tb_offset=0) |
| 1958 | |
| 1959 | def _get_exc_info(self, exc_tuple=None): |
| 1960 | """get exc_info from a given tuple, sys.exc_info() or sys.last_type etc. |
no test coverage detected