Re: signal handling and (structured) exception handling
On Oct 9, 1:18 am, Peter <excessph...@gmail.com> wrote:
I'm a little bit at loss, why the new C++ standard (C++0x)
does not include something like Windows structured exception
handling.
Two reasons, really. The first is a killer: it can't be
implemented on a lot of platforms (e.g. those without memory
management or protection). The second is simply that it is a
bad idea.
I certainly prefer a C++ Exception to a signal, as the signal
only gives you the choice to terminate the process or mess
around with something as ugly as setjmp/longjmp.
And when do you get a structured exception? Only when there is
a serious program error, such that you can no longer be sure of
the environment, and the only reasonable thing (for most
applications) is to abort, as quickly as possible.
And such signals/exceptions can sometimes not be avoided, e.g.
in case of the system runs out of disk space while writing
into memory created by memory mapped io from a sparse file.
Which is definitely a special case; the C++ language itself
doesn't support memory mapped files or sparse files. Whatever
happens in such cases is implementation defined.
Even in case of a null pointer access I would prefer to keep
the application running to be able to terminate it correctly.
So check for null, and do whatever you want.
In this case probably there is no need to try to execute the
last verb again, because it will run into the same null
pointer access -- but at least the destructors should work and
the application can be terminated correctly.
The problem is that when you've got an access violation
(accessing memory which doesn't belong to the process), it's
usually due to some previous memory overwrite, and you can't
(safely) execute destructors.
(This obviously depends on the application. There is a definite
risk that executing destructors will do more harm than good, and
most applications probably shouldn't take that risk, but some,
like games programs, can't do much real harm, and it's worth the
risk.)
--
James Kanze