[SPAM] - Re: [c++-pthreads] pthread_cancel and EH: let's try this again - Email found in subject

[Ted Baker]

On Mon, Jul 18, 2005 at 06:53:23PM +0300, Peter Dimov wrote:
> >Yes, because it is unsafe, and C++ wants to be safer than C.
> 
> I'm not sure I follow. In what way is a cancellation exception less safe 
> than any other exception? 

In this context, I was thinking of the problem of not knowing when
and where such an exception might be thrown.  As others have
pointed out, when you are calling a library function written
in C (whether part of the standard C library or some other library)
you don't know whether it will call something that qualifies as
a thread cancellation point.  This is a problem with C, already,
and wrapping it in C++ does not make the problem go away.

I was also thinking of some of the baroque semantic proposals I've
seen on this e-mail thread, and the difficulty of getting every
programmer to understand these rules sufficiently well to avoid
making errors in usage (especially when those errors are unlikely
to show up in testing).  If people in this group are having
trouble understanding each other's proposals, what about the
"clones" who write most of the world's code?

--Ted

BTW, I can't resist the temptation to make the following
peripheral comments, which I hope will not distract from the
above.

1) If providing access in C++ to everything one can do in C is so
important, why not provide access to the full C signal handling
model?

2) Are exceptions safe, in general?

In the Ada world, I recall some people interested in safety
certification ruled out the use of exceptions entirely.  The core
of their arguments that I remember had to do with: (1) formal
verification; (2) test coverage analysis.

I believe the problem with formal verification had to do with the
proliferation of control paths.  Simple syntax-directed proof
methods, like the classic Hoare precondition-postcondition
assertion rules, rely on having a fixed and known set of "come
from" points for each point for which an assertion is to be
proven.  Exceptional control flow complicates this greatly.

I believe the problem with test coverage analysis is also with the
proliferation of control paths, but goes a bit further.  Some
forms of certification require that all instructions, branches, or
paths be demonstrated to have been executed in testing.  It is
very difficult to generate tests that will force execution of all
exception handlers, much less all paths that may lead through an
exception handler.

While I am not arguing for removing exceptions from any language,
my experience as a professor has supported a degree of skepticism
about the ability of most people to write and maintain correct
code that makes use of exceptions.  I have seen many errors,
usually involving unwarranted assumptions inside an exception
handler about where the exception originated and the state of
variables at the point the handler got control.  I have also seen
correct exception handling code broken, by adding new points from
which an exception can be thrown, or by the addition of a new
handler (catch) that intercepts an exception before it reaches the
old handler.

Of course, there are some simple patterns of usage that are
safe and very useful.  In this regard, there is a strong
analogy between exceptions today and "gotos" before the
advent of structured programming constructs.