Re: signal handling and (structured) exception handling
On Oct 13, 8:19 pm, Peter <excessph...@gmail.com> wrote:
On Oct 12, 1:51 pm, Noah Roberts <d...@reply.com> wrote:
I'm a little bit at loss, why the new C++ standard (C++0x)
does not include something like Windows
structuredexceptionhandling. I certainly prefer a
C++Exceptionto a signal, as the signal only gives you the
choice to terminate the process or mess around with
something as ugly as setjmp/longjmp.
Because signals and exceptions are for totally different
things.
Yes. E.g. "signals" is spelled fully differently than
"exceptions". What is your point?
That they're totally different, unrelated things. Although you
can raise a signal from inside your program, most signals are
triggered from outside the program: a hardware fault or an
external command. As such, they occur completely
asynchronously. An exception only occurs if you explicitly
throw.
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.
Even in case of a null pointer access I would prefer to
keep the application running to be able to terminate it
correctly. 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.
Use a smart pointer and throw anexceptionwhen ->* is called on 0.
This would involve an if-statement which results in additional
machine instructions. The CPU is anyway checking for invalid
memory access.
Only partially:-). None of the hardware I know supports bounds
checking without some additional machine instructions.
More generally: suppose you corrupt the free space arena (as a
result of a pointer error---probably the most common cause of a
segment violation in code I've seen)? You get an access
violation (SIGSEGV in most Unix systems) deep inside malloc
code, when malloc is updating its data structures. How can a
structured exception possibly work in such cases? You can no
longer allocate or free memory without causing another access
violation. Your internal library data structures are fatally
corrupt.
This doesn't mean that structured exceptions are never
appropriate; I'm using them in my current work (and in this
case, they are justified). But they certainly shouldn't be
required; most of the time, they're NOT an appropriate response,
and most implementations can't support them reliably. (I
actually think that no implementation can support them reliably,
given the example I just cited. But there are special cases
where it's worth the risk: a major advantage when they work, and
you don't make the situation significantly worse when they
don't.)
--
James Kanze