By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,929 Members | 1,245 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,929 IT Pros & Developers. It's quick & easy.

R e: Catching access violation exceptions

P: n/a
In article <sl*******************>, Juergen
Heinzl wrote:
In article <f9************************** >, 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*.


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.


Jul 19 '05 #1
Share this question for a faster answer!
Share on Google+

This discussion thread is closed

Replies have been disabled for this discussion.