471,118 Members | 1,023 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,118 software developers and data experts.

R e: Catching access violation exceptions

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*.


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
0 2558

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Rolf | last post: by
2 posts views Thread by Keith Bolton | last post: by
15 posts views Thread by Steven Reddie | last post: by
7 posts views Thread by cmay | last post: by
7 posts views Thread by Derek Schuff | last post: by
5 posts views Thread by Simon Tamman | last post: by
7 posts views Thread by Me | last post: by
12 posts views Thread by Karlo Lozovina | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.