R e: Catching access violation exceptions

[Steven Reddie]

In article <sl*******************@monocerus.manannan.org>, Juergen
Heinzl wrote:

In article <f9**************************@posting.google.com >, Steven Reddie wrote:

I understand that access violations aren't part of the standard C++
exception handling support. On Windows, a particular MSVC compiler
option enables Microsoft's Structured Exception Handling (SEH) in C++ EH so that a catch (...) will catch an access violation. I don't know if other platforms support something similar.

I'm wondering about how to best protect an application or library from poorly written user-defined callbacks. It would be nice to be able to automatically unregister a user-defined callback if it is found to
cause any exception including access violations. Does anyone know of a platform-independant method for achieving this?

[-]
No, not really. You can use whatever signal handling is available,
though signals aren't a C++ thing.

So staying off topic of this group for a little bit more IMHO the

wholeidea of trying to "fix" anything during runtime here isn't such a greatidea either as a signal may be risen *after* some damage has been alreadydone and so from there on all bets are off.

Say should your application be some sort of flight control system pleaselet me leave the plane *NOW*.

Cheers,
Juergen

I understand the concern, but being able to do this has a use that
supports your point of view. That is that if I can catch an access
violation when calling a user-provided DLL I know that an error
occured. Even if rebooting the system is the best option I can at
least attempt to disable that DLL from being used the next time. A
simple "reboot on access violation because the system is in an unknown
state" approach would mean that I keep hitting the same problem and
the plane crashes anyway. Also, assuming that an access violation
means that the system must be rebooted immediately may be just as bad
as assuming that no access violation means that the system is okay.
Catching an access violation is only important in this case if a DLL
is dodgy, and if you may have a dodgy DLL isn't best to do all you can
to detect and recover than do nothing at all? Sure, the system may be
in such a state after an access violation that attempting to flag the
DLL as disabled may not succeed, but if the sh*t hits the fan you have
to do the best you can.

Regards,

Steven