Re: signal handling and (structured) exception handling
On Oct 14, 5:43 pm, Peter <excessph...@gmail.com> wrote:
On Oct 14, 1:40 am, James Kanze <james.ka...@gmail.com> wrote:
More generally, implementable or not, structured exceptions
aren't reliable. There are special cases (e.g. plug-ins for
non-critical applications) where they represent an acceptable
risk, especially since with the Microsoft compiler, each plug-in
(DLL) has its own heap, but I certainly wouldn't use them in
anything critical.
I'm not following. I posted here some scenarious, in which
structured exception handling would be fully reliable:
* writing into memory created via memory mapped io of sparse files
* doing long floating point calculations
But you either have structured exceptions, or you don't. A lot
of the time they might occur (e.g. dereferencing a null
pointer), they will be reliable. Other times, however, they
won't be, and if you have them, you have to deal with those
times as well (or accept the risk of undefined behavior).
Again, I repeat: I'm not arguing against structured exceptions
when they're appropriate---I currently use them. I'm just
saying that you can't make them a required part of the standard,
because they aren't appropriate in most cases (and they can't be
implemented reliably on most platforms). If you wanted to
standardize them, you'd have to define what happens in cases
where they do occur because the free space arena or the stack
has been corrupted: the current standard just says undefined
behavior in these cases, a requirement any implementation can
meet. Try defining a behavior in such cases that you can
guarantee will be met, even by the Microsoft implementation, and
you'll find that it can't be done.
--
James Kanze