Re: signal handling and (structured) exception handling
On Oct 13, 8:31 pm, Peter <excessph...@gmail.com> wrote:
On Oct 12, 12:28 pm, James Kanze <james.ka...@gmail.com> wrote:
The standard could simply claim, that on machines which
support memory protection, a C++exceptionshould be thrown
instead of a signal. This would cover all of the platforms
I have to deal with (various UNIXs and Windows).
Except that this can't be made to work under Solaris, on a
Sparc.
SOLARIS also has signals for SIGSEGV and floating point exceptions.
Yes, but you can't throw an exception from a signal handler.
I used to convert structured exceptions on Windows into C++
exceptions by setting the matching handler and throw from this
handler a C++ exception matching the structured exception code
-- to be able to catch different types of exceptions depending
on what had happend.
Once you have a structured exception under Windows, you are in
the exception handling mechanism.
Both, the signal handlers and structured exception handling are
asynchron.
Under Windows. Most systems don't support asynchronous
exceptions; it's not trivial.
I think it is just a matter of the compiler -- to create code,
which is able to deal with exceptions thrown from a signal
handler -- compiler switch /EHa with Microsofts Visual C++.
It depends more on the API, and how the stack is set up. Under
Solaris, on a Sparc, at least, there are moments when a stack
walkback is not possible. Throw an exception in one of these,
and you're hosed. (I really suspect that the same thing is true
under Windows, and that there are combinations of circumstances
where structured exceptions don't work. Ensuring that you can
trigger a stack walkback asynchronously can be very expensive in
terms of runtime, even on an 80x86.)
And more generally, the fact that C++ doesn't throw
anexceptionin such cases is a major reason why people
continue to use it---if there is an error in your code,
anexceptionis the last thing you want. (A C++exception,
anyway, with destructors being called.)
I'm not following.
You are saying, that the reason people use C++ exception handling is
that it does not cover SIGSEGV?
No. I'm saying that one reason people use C++ (instead of e.g.
Java) is because it doesn't convert e.g. a null pointer
dereference into an exception, but rather aborts the process.
(It's only one reason, of course. There are a lot of others.)
I've never heared anybody complain about the existence of
structured exception handling on Windows.
That's because most serious programmers don't use it. In most
contexts, I'll compile with /EHs.
Note that I'm all in favor of compilers offering structured
exceptions as an option, if they can. There are cases where it
is useful and appropriate. But it would be a serious flaw in
the language to require it, because most of the time, it is not
a good solution, and because most system API's can't reliably
support it. This is one case where "undefined behavior" is
precisely the best possible solution, since it leaves the
implementor free to offer the best solution possible for his
customers, on his platforms. Including offering a choice of
solutions, as does Microsoft.
Please explain why you could not do whatever you are doing in
a signal handler in the matching exception handler (which is
also a function which can be installed like a signal handler).
Because a signal can occur asynchronously. At the moment the
code is adjusting the stack, for example. It's often possible
to ensure that there is no critical moment (although I don't
think it's possible on a Sparc, given the way the register stack
works), but requiring this also excludes any number of
optimization techniques, which means that many applications will
take a performance hit from it.
--
James Kanze