STINNER Victor <victor.stin...@gmail.com> added the comment:
> So I think our choices are:
> * report no C++/CLR exceptions via faulthandler
> * report all C++/CLR exceptions via faulthandler (current behaviour)
>
> I'm inclined towards changing to the first option. (...)
On the Internet, I found users asking why their favorite application crashed
with "Unhandled Exception E0434F4D (e0434fedh) at address 7C81EB33h" or
"APPCRASH Exception Code e0434f4d".
While I understand that it's annoying to get a traceback each time an
application handles an exception, the faulthandler would leave the user
clueless if faulthandler ignore such exception and the exception "kills" the
process.
faulthandler registers its exception handler as the *first* handler to be
called:
AddVectoredExceptionHandler(1, faulthandler_exc_handler);
Maybe it shouldn't be the first but the *last* to be called? So an earlier
handler could handle the exception, and faulthandler wouldn't log its traceback.
The problem is that I'm confused with "non-error" exceptions (code <
0x80000000), "expected" MSC or COM exceptions, and fatal exceptions like
EXCEPTION_INT_DIVIDE_BY_ZERO or EXCEPTION_ACCESS_VIOLATION.
Is it possible to be asked to be called as the last handler, and still be able
to log EXCEPTION_ACCESS_VIOLATION? If not, maybe we need two handlers depending
on the exception code. One handler called last for non-fatal exceptions, one
handler called first for fatal exceptions.
By "Fatal" exceptions, I mean:
case EXCEPTION_ACCESS_VIOLATION: PUTS(fd, "access violation"); break;
case EXCEPTION_FLT_DIVIDE_BY_ZERO: PUTS(fd, "float divide by zero"); break;
case EXCEPTION_FLT_OVERFLOW: PUTS(fd, "float overflow"); break;
case EXCEPTION_INT_DIVIDE_BY_ZERO: PUTS(fd, "int divide by zero"); break;
case EXCEPTION_INT_OVERFLOW: PUTS(fd, "integer overflow"); break;
case EXCEPTION_IN_PAGE_ERROR: PUTS(fd, "page error"); break;
case EXCEPTION_STACK_OVERFLOW: PUTS(fd, "stack overflow"); break;
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31701>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
