In article <4v************ ********@pipex. net>,
sg*******@dNiOa Sl.PpAiMpPeLxE. AcSoEm says...
[ ... ]
Hmm :) Assuming your recollection is accurate, it does make a fair amount of
sense. It's a tad unfortunate that it went that way, though. Oh well, I
suppose we'll just have to make do without using exception specifications.
I originally thought it was unfortunate, but I've changed my mind. I've
since become convinced that exception specifications (at least as
currently defined) are a fundamentally mistaken design that runs
directly counter to the intent and usefulness of exception handling in
the first place.
One of the basic ideas of exception handling is that the code that
detects a problem rarely has the context to deal appropriately with that
problem -- and in fact, the two will be separated by some arbitrary (but
often large) distance both conceptually and in the call chain. One of
the primary advantages of exception handling is that it allows the
intermediate levels in that call chain to ignore all but those
exceptions can (at least help to) handle. Other than that, their sole
obligation is to be written in an exception-safe fashion.
Exception specifications directly violate that, however. Instead of
allowing all the intermediate levels to ignore all but the exceptions to
which they can contribute handling, exception specifications demand that
all the software, at all the intermediate layers, excplicitly know and
acknowledge _all_ of the exceptions that might orignate from anything
they might call. This is not merely impractical, but negates much (if
not most) of the advantage exception handing provides in the first
place.
I believe virtually nobody really even _wants_ this. What they really
want isn't an assurance that every level in a call chain is aware of all
the exceptions that may originate down the call chain. Rather, the want
an assurance that some code at SOME level in the call chain knows how to
handle all of the exceptions that may happen in whatever it calls. If we
could do THAT at compile time (or more likely link time, since it needs
a view of the program as a whole) it would probably be truly worthwhile.
Exception specifications wouldn't really be very helpful in that though.
To enforce this at compile time, we'd basically start from the lowest
level in a particular call stack, and put together a list of all the
exceptions that can be thrown from that level. We'd then take a step up
the call stack, and add in all the exceptions that level can throw, and
so on. At each level we'd also look for any exception handlers, and
examine their contents to see what exceptions that came from below would
be caught at that level. We'd have to look at the contents of the
handler to see whether it re-throws the current exception. Those that
are caught but not re-thrown could be subtracted from the list of
possible exception. Of course, the compiler would also have to take
inheritance into account -- catching a base class obviously catches all
derived classes.
If there are any exceptions left in the list when we've looked at any
exception handlers in main, these are exceptions that can be thrown but
never caught. Being able to give at least a warning for that situation
would almost certainly be useful. The difficult part of this analysis
would probably be intermediate catch blocks that might only re-throw an
exception conditionally -- and if the condition related to the type of
the exception, it could be difficult to sort out which exceptions that
were caught mnight be re-thrown and which never would.
--
Later,
Jerry.
The universe is a figment of its own imagination.
