Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Exception Specifications

Reply
Thread Tools

Exception Specifications

 
 
Stuart Golodetz
Guest
Posts: n/a
 
      09-23-2006
"Jerry Coffin" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> In article <(E-Mail Removed)>,
> http://www.velocityreviews.com/forums/(E-Mail Removed)Em says...
>> Hi all,
>>
>> Just wondering whether there's any reason why exception specifications
>> are
>> enforced at runtime, rather than at compile-time like in Java? (This was
>> prompted by reading an article on GOTW, incidentally.) Is there something
>> about C++ that makes it harder/impossible to check at compile-time?

>
> The following is based primarily on recollection, so it may need to be
> taken with a grain of salt.
>
> In a phrase, backward compatibility. Exception specifications were added
> to C++ after there were a number of implementations of exception
> handling. These were consistent enough that it was considered reasoanble
> and important to maintain compatibility with them. To maintain
> compatibility with this code, the rule was made that lack of an
> exception specification meant "can throw anything."
>
> Unfortunately, that also meant that essentially all existing code was
> seen (by the compiler) as being able to throw anything -- even pure C
> code that had no notion of exception handling at all.
>
> If exception specifications were enforced at compile time, new code that
> used them would have had to do one of two things: either rewrite all
> existing code to include exception speciifications (incidentally,
> breaking all C compatibility) or else include a 'catch(...)' clause in
> the new code to catch and convert the (probably nonexistent) "other"
> exceptions to something it was allowed to throw.
>
> Neither of these was seen as acceptable, leaving run-time enforcement as
> nearly the only possible solution.
>
> --
> Later,
> Jerry.
>
> The universe is a figment of its own imagination.


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.
Thanks for the explanation, anyhow.

Cheers,
Stu


 
Reply With Quote
 
 
 
 
Jerry Coffin
Guest
Posts: n/a
 
      09-24-2006
In article <(E-Mail Removed)>,
(E-Mail Removed)Em 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.
 
Reply With Quote
 
 
 
 
Dave Steffen
Guest
Posts: n/a
 
      09-25-2006
"Stuart Golodetz" <(E-Mail Removed)> writes:

> "Jerry Coffin" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > In article <(E-Mail Removed)>,
> > (E-Mail Removed)Em says...
> >> Hi all,
> >>
> >> Just wondering whether there's any reason why exception
> >> specifications are enforced at runtime, rather than at
> >> compile-time like in Java?

[...]
> > Neither of these was seen as acceptable, leaving run-time enforcement as
> > nearly the only possible solution.


> 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. Thanks for the explanation, anyhow.


One other issue, though: exception specifications are IIRC nearly
impossible to deal with correctly when writing templates. You don't
know, when writing the template (either function or class) what
operations on the templated type may or may not throw, nor do you
know what do to with them. I don't think anybody's come up with a
good way for templates and exception specs to play nicely together.

----------------------------------------------------------------------
Dave Steffen, Ph.D.
Software Engineer IV Disobey this command!
Numerica Corporation - Douglas Hofstadter
dgsteffen at numerica dot us
 
Reply With Quote
 
Geo
Guest
Posts: n/a
 
      09-25-2006

Stuart Golodetz wrote:
> Hi all,
>
> Just wondering whether there's any reason why exception specifications are
> enforced at runtime, rather than at compile-time like in Java? (This was


C++ is NOT Java, why would you even hope that it might work the same,
especially since Java exception handling is horrible, at least C++'s is
so broken that it is unusable (in fact it is dangerous to use it), and
therefore you never neeed to worry about it.

> prompted by reading an article on GOTW, incidentally.) Is there something
> about C++ that makes it harder/impossible to check at compile-time?
>
> Cheers,
> Stu


 
Reply With Quote
 
Roland Pibinger
Guest
Posts: n/a
 
      09-25-2006
On 25 Sep 2006 09:17:22 -0700, "Geo" <(E-Mail Removed)> wrote:
>C++ is NOT Java, why would you even hope that it might work the same,
>especially since Java exception handling is horrible, at least C++'s is
>so broken that it is unusable (in fact it is dangerous to use it), and
>therefore you never neeed to worry about it.


Neither is Java exception handling 'horrible' (it's just different
from C++) nor are C++ exception specifications 'broken'. WRT to the
latter you propagate the widespread 'Stroustrup-had-a-bad-day' myth.
It declares that everything in the C++ language is fine (more or
less), just exception specifications are 'broken' and 'unusable'. The
same article is usually quoted as reference.
It's true that C++ exception specifications are not standardized in
the most practical way (they are not even standardized as Stroustrup
describes them in his book). But they are not more 'broken' than other
C++ language elements like templates or the look-up rules.
Exception specifications make sense for at least 2 use cases:
1. you guarantee that no exception is thrown form a (usually low
level) function. This eg. is important to implement assignment
operators.
2. you guarantee that the specified and only the specified
exception(s) is(are) thrown from a function. Since exception
specifications are part of the contract between the user and you, the
implementer, all high level library interfaces should explicitly
specify exceptions in code.

Best regards,
Roland Pibinger

 
Reply With Quote
 
Bart
Guest
Posts: n/a
 
      09-25-2006
Roland Pibinger wrote:
> On 25 Sep 2006 09:17:22 -0700, "Geo" <(E-Mail Removed)> wrote:
> >C++ is NOT Java, why would you even hope that it might work the same,
> >especially since Java exception handling is horrible, at least C++'s is
> >so broken that it is unusable (in fact it is dangerous to use it), and
> >therefore you never neeed to worry about it.

>
> Neither is Java exception handling 'horrible' (it's just different
> from C++) nor are C++ exception specifications 'broken'. WRT to the
> latter you propagate the widespread 'Stroustrup-had-a-bad-day' myth.
> It declares that everything in the C++ language is fine (more or
> less), just exception specifications are 'broken' and 'unusable'. The
> same article is usually quoted as reference.
> It's true that C++ exception specifications are not standardized in
> the most practical way (they are not even standardized as Stroustrup
> describes them in his book). But they are not more 'broken' than other
> C++ language elements like templates or the look-up rules.
> Exception specifications make sense for at least 2 use cases:
> 1. you guarantee that no exception is thrown form a (usually low
> level) function. This eg. is important to implement assignment
> operators.
> 2. you guarantee that the specified and only the specified
> exception(s) is(are) thrown from a function. Since exception
> specifications are part of the contract between the user and you, the
> implementer, all high level library interfaces should explicitly
> specify exceptions in code.


You also guarantee that your whole aplication will crumble whenever you
or anything that you call breaks that contract. I really don't see the
point, beside the moderate documentation value of such specifications.
But even then, everyone knows that destructors and assignment operators
are nothrow.

Yes, crashing early is better, yes, I know about all the pretty stuff
like "contracts" that looks very good on whiteboards and in
conferences. But when you get down to pragmatic every-day details a
contract like this may not even be enforceable in a dynamic run-time
environment where many things can happen, and bringing the whole
application down because one of the zillions of components broke its
contract is not acceptable in many real world situations.

Regards,
Bart.

 
Reply With Quote
 
Roland Pibinger
Guest
Posts: n/a
 
      09-25-2006
On 25 Sep 2006 10:59:22 -0700, "Bart" <(E-Mail Removed)> wrote:
>You also guarantee that your whole aplication will crumble whenever you
>or anything that you call breaks that contract...
>Yes, crashing early is better, yes, I know about all the pretty stuff
>like "contracts" that looks very good on whiteboards and in
>conferences. But when you get down to pragmatic every-day details a
>contract like this may not even be enforceable in a dynamic run-time
>environment where many things can happen, and bringing the whole
>application down because one of the zillions of components broke its
>contract is not acceptable in many real world situations.


You seem to belief that one cannot programmatically control which
exception(s) may be thrown from a function (and therefore not use
except. spec.). Of course, you can. As a library user I want reliable
information about what a function may throw, eg.

class Database {
public:
void connect (...) throw (DBexcept);
};

or maybe even

class Database {
public:
ErrorCode connect (...) throw();
};


Best wishes,
Roland Pibinger
 
Reply With Quote
 
Bart
Guest
Posts: n/a
 
      09-25-2006

Roland Pibinger wrote:
> On 25 Sep 2006 10:59:22 -0700, "Bart" <(E-Mail Removed)> wrote:
> >You also guarantee that your whole aplication will crumble whenever you
> >or anything that you call breaks that contract...
> >Yes, crashing early is better, yes, I know about all the pretty stuff
> >like "contracts" that looks very good on whiteboards and in
> >conferences. But when you get down to pragmatic every-day details a
> >contract like this may not even be enforceable in a dynamic run-time
> >environment where many things can happen, and bringing the whole
> >application down because one of the zillions of components broke its
> >contract is not acceptable in many real world situations.

>
> You seem to belief that one cannot programmatically control which
> exception(s) may be thrown from a function (and therefore not use
> except. spec.). Of course, you can. As a library user I want reliable
> information about what a function may throw, eg.
>
> class Database {
> public:
> void connect (...) throw (DBexcept);
> };


So what do you do when your network connection fails? Or when a simple
memory allocation fails? Do you catch every possible exception and then
re-throw the corresponding DBexcept equivalent? What practical value is
added by this approach as opposed to just letting everything that you
don't care about go through?

Besides, trivial examples are great for classrooms and CTO meatings but
in general they are of fairly limited applicability. What do you do
when a third party plug-in doesn't respect its contract? Do you just
die because you didn't expect it?

Regards,
Bart.

 
Reply With Quote
 
Bart
Guest
Posts: n/a
 
      09-25-2006

Bart wrote:
> Roland Pibinger wrote:
> > On 25 Sep 2006 10:59:22 -0700, "Bart" <(E-Mail Removed)> wrote:
> > >You also guarantee that your whole aplication will crumble whenever you
> > >or anything that you call breaks that contract...
> > >Yes, crashing early is better, yes, I know about all the pretty stuff
> > >like "contracts" that looks very good on whiteboards and in
> > >conferences. But when you get down to pragmatic every-day details a
> > >contract like this may not even be enforceable in a dynamic run-time
> > >environment where many things can happen, and bringing the whole
> > >application down because one of the zillions of components broke its
> > >contract is not acceptable in many real world situations.

> >
> > You seem to belief that one cannot programmatically control which
> > exception(s) may be thrown from a function (and therefore not use
> > except. spec.). Of course, you can. As a library user I want reliable
> > information about what a function may throw, eg.
> >
> > class Database {
> > public:
> > void connect (...) throw (DBexcept);
> > };

>
> So what do you do when your network connection fails? Or when a simple
> memory allocation fails? Do you catch every possible exception and then
> re-throw the corresponding DBexcept equivalent? What practical value is
> added by this approach as opposed to just letting everything that you
> don't care about go through?
>
> Besides, trivial examples are great for classrooms and CTO meatings but


Typo there. Should be 'meetings'.

Regards,
Bart.

 
Reply With Quote
 
Gavin Deane
Guest
Posts: n/a
 
      09-25-2006

Bart wrote:
> Besides, trivial examples are great for classrooms and CTO meatings but
> in general they are of fairly limited applicability. What do you do
> when a third party plug-in doesn't respect its contract? Do you just
> die because you didn't expect it?


The first thing you should do is consider an alternative supplier. As
long as the concept of a third party plug-in (or any other API) failing
to respect its contract[*] is considered by users of plug-ins to be in
any way expected or acceptable, software engineering will remain the
woefully immature discipline it currently is.

Gavin Deane

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Exception Specifications Keith Halligan C++ 7 05-06-2008 09:38 AM
C++0x/1x exception specifications proposal: Compile-time checked Ioannis Vranos C++ 22 01-22-2008 07:55 PM
where do exception specifications go? ab2305@gmail.com C++ 4 10-06-2005 05:02 PM
Exception Specifications Using Undefined Class Scott Brady Drummonds C++ 1 07-29-2004 10:35 PM
Compilers that do implement C++ Exception Specifications Philipp Holzschneider C++ 6 10-02-2003 06:16 PM



Advertisments