> 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;