473,320 Members | 1,950 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Exception Specifications

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?

Cheers,
Stu
Sep 23 '06 #1
41 2987
Stuart Golodetz wrote:
Just wondering whether there's any reason why exception specifications are
enforced at runtime, rather than at compile-time like in Java?
Beacause is a loose of time. I've seen plenty of Java code samples full of:

try something; catch anything required by the specification: Do nothing;

--
Salu2
Sep 23 '06 #2
"Julián Albo" <JU********@terra.eswrote in message
news:45********@x-privat.org...
Stuart Golodetz wrote:
>Just wondering whether there's any reason why exception specifications
are
enforced at runtime, rather than at compile-time like in Java?

Beacause is a loose of time. I've seen plenty of Java code samples full
of:

try something; catch anything required by the specification: Do nothing;

--
Salu2
Whether exception specifications are a good thing or not is certainly up for
discussion :) What I don't understand though is what purpose is served by
enforcing them at runtime. If you're going to enforce them, surely it should
be at compile-time? I was just wondering if there's some technical
difficulty making that impossible, or at any rate very hard?

Cheers,
Stu
Sep 23 '06 #3

Stuart Golodetz skrev:
"Julián Albo" <JU********@terra.eswrote in message
news:45********@x-privat.org...
Stuart Golodetz wrote:
Just wondering whether there's any reason why exception specifications
are
enforced at runtime, rather than at compile-time like in Java?
Beacause is a loose of time. I've seen plenty of Java code samples full
of:

try something; catch anything required by the specification: Do nothing;

--
Salu2

Whether exception specifications are a good thing or not is certainly up for
discussion :) What I don't understand though is what purpose is served by
enforcing them at runtime. If you're going to enforce them, surely it should
be at compile-time? I was just wondering if there's some technical
difficulty making that impossible, or at any rate very hard?
I believe it is hard. Consider:

std::vector<intv;
.....

int i = v.size() 0? v.at(0):0;
Should that statement be assumed to throw or not?
While it is easy for us to see, it is more difficult for a compiler.
And it can be made even more difficult if v.at(0) is replaced by a
function-call with v as a parameter. I believe you can see the point?

/Peter

Cheers,
Stu
Sep 23 '06 #4
Stuart Golodetz wrote:
>try something; catch anything required by the specification: Do nothing;
Whether exception specifications are a good thing or not is certainly up
for discussion :) What I don't understand though is what purpose is served
by enforcing them at runtime. If you're going to enforce them, surely it
should be at compile-time?
As shown by my sample, checking it at compile time does not enforce
anything. When people see a message from the compiler, immediately add code
like this. Or instead of doing nothing they abort the program, thus
effectively doing the check at runtime but having to write code to do it.

Surely C++ compilers can add a check and issue a warning when explicit
violations of the specification are detected, the reason they not do it is
that almost anybody wants it.
I was just wondering if there's some technical difficulty making that
impossible, or at any rate very hard?
People habitually don't add features or options to a compiler, or any other
program of certain size and complexity, just because there is not
impossible or very hard to do it. They do it when the authors think, or a
bunch of users tell him, that it will be useful.

If you are talking about the language standard, not the features of concrete
compilers, I suggest you to read "The design and evolution of C++".

--
Salu2
Sep 23 '06 #5
peter koch wrote:
I believe it is hard. Consider:

std::vector<intv;
....

int i = v.size() 0? v.at(0):0;
Should that statement be assumed to throw or not?
By the point of view of checking specifications is easy: the statement can
throw if and only if vector::size or vector::at can throw.
And it can be made even more difficult if v.at(0) is replaced by a
function-call with v as a parameter. I believe you can see the point?
In that case, the specification of that function is checked, same difficult.

--
Salu2
Sep 23 '06 #6
"Stuart Golodetz" <sg*******@dNiOaSl.PpAiMpPeLxE.AcSoEmwrites:
Whether exception specifications are a good thing or not is certainly up for
discussion :) What I don't understand though is what purpose is served by
enforcing them at runtime. If you're going to enforce them, surely it should
be at compile-time? I was just wondering if there's some technical
difficulty making that impossible, or at any rate very hard?
I disagree with the other answers to your question - I find exception
specifications almost useless for that reason; and in practice, indeed
most people don't use them. To quote Herb Sutter:

'In brief, don't bother with exception specifications. Even experts
don't bother.'

And the boost coding guidelines discourage using them either.

There are some minor uses for them that have to do with optimisations
a compiler can do when he knows that exceptions can't occur, but they
are really unusable for what they are for in language like java: To
document what functions throw and enforce this documenation.

If someone know why exception specifications are as brain-dead as they
are in C++, I'd be intruiged to hear. My guess is some compatibility
rationale.

Jens
Sep 23 '06 #7
Julián Albo wrote:
peter koch wrote:
>I believe it is hard. Consider:

std::vector<intv;
....

int i = v.size() 0? v.at(0):0;
Should that statement be assumed to throw or not?

By the point of view of checking specifications is easy: the
statement can throw if and only if vector::size or vector::at can
throw.
But vector::size doesn't throw, and vector::at isn't called if the
condition is such that it could throw. So is this statement throwing
or not? Can the compiler detects that?
>
>And it can be made even more difficult if v.at(0) is replaced by a
function-call with v as a parameter. I believe you can see the
point?

In that case, the specification of that function is checked, same
difficult.
The other problem is with templates, where the throw spec really
depends on the template parameter

template<class T>
void do_something(T x); // might throw for some Ts

How do we express that?
Bo Persson
Sep 23 '06 #8
Bo Persson wrote:
>>int i = v.size() 0? v.at(0):0;
Should that statement be assumed to throw or not?

By the point of view of checking specifications is easy: the
statement can throw if and only if vector::size or vector::at can
throw.

But vector::size doesn't throw, and vector::at isn't called if the
condition is such that it could throw. So is this statement throwing
or not? Can the compiler detects that?
What compiler? Maybe a compiler that does it can be written, at least for
standard functions with well defined behavior, but I don't think there is a
great demand for such feature. By the way, in this example you can drop
'at' and use operator [ ] instead.
The other problem is with templates, where the throw spec really
depends on the template parameter
template<class T>
void do_something(T x); // might throw for some Ts
How do we express that?
I suppose that a compiler that check the specifications at compile time
'java style' will check at complete specialization of the template time.
Supposing that such compiler will exist any time. One can imagine a
sintaxis to express something as: "can throw what T::somefunc throws", but
I suspect that such complications will never be used by any programmer.

--
Salu2
Sep 23 '06 #9
In article <AL********************@pipex.net>,
sg*******@dNiOaSl.PpAiMpPeLxE.AcSoEm 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.
Sep 23 '06 #10
"Jerry Coffin" <jc*****@taeus.comwrote in message
news:MP***********************@news.sunsite.dk...
In article <AL********************@pipex.net>,
sg*******@dNiOaSl.PpAiMpPeLxE.AcSoEm 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
Sep 23 '06 #11
In article <4v********************@pipex.net>,
sg*******@dNiOaSl.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.
Sep 23 '06 #12
"Stuart Golodetz" <sg*******@dNiOaSl.PpAiMpPeLxE.AcSoEmwrites:
"Jerry Coffin" <jc*****@taeus.comwrote in message
news:MP***********************@news.sunsite.dk...
In article <AL********************@pipex.net>,
sg*******@dNiOaSl.PpAiMpPeLxE.AcSoEm 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
Sep 25 '06 #13
Geo

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
Sep 25 '06 #14
On 25 Sep 2006 09:17:22 -0700, "Geo" <gg@remm.orgwrote:
>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

Sep 25 '06 #15
Roland Pibinger wrote:
On 25 Sep 2006 09:17:22 -0700, "Geo" <gg@remm.orgwrote:
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.

Sep 25 '06 #16
On 25 Sep 2006 10:59:22 -0700, "Bart" <ba***********@gmail.comwrote:
>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
Sep 25 '06 #17

Roland Pibinger wrote:
On 25 Sep 2006 10:59:22 -0700, "Bart" <ba***********@gmail.comwrote:
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.

Sep 25 '06 #18

Bart wrote:
Roland Pibinger wrote:
On 25 Sep 2006 10:59:22 -0700, "Bart" <ba***********@gmail.comwrote:
>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.

Sep 25 '06 #19

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

Sep 25 '06 #20
Jens Theisen <jt***@arcor.dewrote:
>"Stuart Golodetz" <sg*******@dNiOaSl.PpAiMpPeLxE.AcSoEmwrites:
>Whether exception specifications are a good thing or not is certainly up for
discussion :) What I don't understand though is what purpose is served by
enforcing them at runtime. If you're going to enforce them, surely it should
be at compile-time? I was just wondering if there's some technical
difficulty making that impossible, or at any rate very hard?

I disagree with the other answers to your question - I find exception
specifications almost useless for that reason; and in practice, indeed
most people don't use them. To quote Herb Sutter:
[...]
>If someone know why exception specifications are as brain-dead as they
are in C++, I'd be intruiged to hear. My guess is some compatibility
rationale.
Essentially, exception specifications are a wonderful idea in basic
principle, but no one really knows how to design them.

There are two major approaches, and both have serious problems. Java chose
static enforcement (at compile time, as suggested above), and C++ chose
dynamic enforcement. Interestingly, I see Java people ask "why not enforce
these dynamically?" about as often as I see C++ people ask "why not
enforce these statically?"

Briefly:

When you go down the Java path, people love exception specifications until
they find themselves all too often encouraged, or even forced, to add
"throws Exception," which immediately renders the exception specification
entirely meaningless. (Example: Imagine writing a Java generic that
manipulates an arbitrary type T...)

When you go down the C++ path, people love exception specifications until
they discover that violating one means invoking terminate, which is almost
never what you want.

For more, see:

"A Pragmatic Look At Exception Specifications"
C/C++ Users Journal, 20(7), July 2002.
http://www.gotw.ca/publications/mill22.htm

particularly the "Issue the Second" subhead.

Herb

---
Herb Sutter (www.gotw.ca) (www.pluralsight.com/blogs/hsutter)

Convener, ISO WG21 (C++ standards committee) (www.gotw.ca/iso)
Architect, Developer Division, Microsoft (www.gotw.ca/microsoft)
Sep 25 '06 #21
rp*****@yahoo.com (Roland Pibinger) writes:
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.
In what way do provide exception specifications more than catch
blocks?

void foo() throw()
{
...
}

is basically equivalent to

void foo()
{
...
}
catch(...)
{
unexpected();
}

So what's good about them?

Jens
Sep 25 '06 #22
Herb Sutter <hs*****@gotw.cawrites:
For more, see:

"A Pragmatic Look At Exception Specifications"
C/C++ Users Journal, 20(7), July 2002.
http://www.gotw.ca/publications/mill22.htm

particularly the "Issue the Second" subhead.
Actually, my quote was from that article. :-) It's not there
following your link, I took it from `exceptional c++ design'.

I can't tell if I would be happy with the Java approach - I'm not
experienced enough in Java to tell. But don't we agree that, in their
current form in C++, they are a redudant nuisance for compiler vendors
and a waste of time for any curious newbie to the language? I may be
harsh, but what is the benefit if there is any?

Regards,

Jens
Sep 25 '06 #23
>Besides, trivial examples are great for classrooms and CTO meatings but
>in general they are of fairly limited applicability.
The following article provides a balanced view of C++ exception
handling and esp. exception specifications. In sum:

"Not every function in a component or layer should be capable of
dealing with exceptions. Usually, try blocks and associated catch
clauses are used by functions that are the entry points into a program
component. The catch clauses are designed to handle exceptions that
the component does not want to let propagate to higher levels of the
program. Exception specifications (...) are also used with the
functions that are the entry points into a component to guard against
the escape of unwanted exceptions to higher levels of the program."

http://www.informit.com/articles/pri...p?p=31537&rl=1

Sep 25 '06 #24
Jens Theisen wrote:
Herb Sutter <hs*****@gotw.cawrites:

>>For more, see:

"A Pragmatic Look At Exception Specifications"
C/C++ Users Journal, 20(7), July 2002.
http://www.gotw.ca/publications/mill22.htm

particularly the "Issue the Second" subhead.


Actually, my quote was from that article. :-) It's not there
following your link, I took it from `exceptional c++ design'.

I can't tell if I would be happy with the Java approach - I'm not
experienced enough in Java to tell. But don't we agree that, in their
current form in C++, they are a redudant nuisance for compiler vendors
and a waste of time for any curious newbie to the language? I may be
harsh, but what is the benefit if there is any?
The only benefit (and a marginal one at that) is as a documentation aid
for drivers at the bottom of a call chain. Once a function calls
another, they become a nuisance.

--
Ian Collins.
Sep 25 '06 #25
"Jens Theisen" <jt***@arcor.dewrote in message
news:87************@arcor.de...
Herb Sutter <hs*****@gotw.cawrites:
>For more, see:

"A Pragmatic Look At Exception Specifications"
C/C++ Users Journal, 20(7), July 2002.
http://www.gotw.ca/publications/mill22.htm

particularly the "Issue the Second" subhead.

Actually, my quote was from that article. :-) It's not there
following your link, I took it from `exceptional c++ design'.

I can't tell if I would be happy with the Java approach - I'm not
experienced enough in Java to tell. But don't we agree that, in their
current form in C++, they are a redudant nuisance for compiler vendors
and a waste of time for any curious newbie to the language? I may be
harsh, but what is the benefit if there is any?

Regards,

Jens
I wouldn't really describe myself as experienced where Java is concerned,
but I've been coding for the last couple of years in it rather than in C++
(for reasons to do with my course) and I don't find the Java way of doing it
especially onerous. I quite like it, actually, which was partly why I
wondered if there was a reason it couldn't be done like that in C++. (I know
different languages do things differently - that's often a good thing - but
exception specifications in C++ aren't exactly ideal.)

Regards,
Stu
Sep 26 '06 #26
"Jens Theisen" <jt***@arcor.dewrote in message
news:87************@arcor.de...
rp*****@yahoo.com (Roland Pibinger) writes:
>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.

In what way do provide exception specifications more than catch
blocks?

void foo() throw()
{
...
}

is basically equivalent to

void foo()
{
...
}
catch(...)
{
unexpected();
}

So what's good about them?

Jens
As implemented, not much, as far as I can see. I think that's the conclusion
to draw, unfortunately.

Stu
Sep 26 '06 #27
"Bart" <ba***********@gmail.comwrote in message
news:11*********************@d34g2000cwd.googlegro ups.com...
>
Roland Pibinger wrote:
>On 25 Sep 2006 10:59:22 -0700, "Bart" <ba***********@gmail.comwrote:
>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?
In Java you have checked and unchecked exceptions. Things like memory errors
would be unchecked exceptions which don't have to be included as part of the
exception specification.
Besides, trivial examples are great for classrooms and CTO meetings 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.
Get an alternative one, work around the problem, write your own, ... The
point about having compile-time exception specifications (if possible) is
that it never gets to the stage where the program will terminate because of
some unexpected exception. The specifications get checked only when you
compile the code. Unfortunately that's not the way exception specifications
work in C++, apparently for various reasons suggested elsewhere in the
thread.

Regards,
Stu
Sep 26 '06 #28

Stuart Golodetz wrote:
"Jens Theisen" <jt***@arcor.dewrote in message
news:87************@arcor.de...
I wouldn't really describe myself as experienced where Java is concerned,
but I've been coding for the last couple of years in it rather than in C++
(for reasons to do with my course) and I don't find the Java way of doing it
especially onerous. I quite like it, actually, which was partly why I
wondered if there was a reason it couldn't be done like that in C++. (I know
different languages do things differently - that's often a good thing - but
exception specifications in C++ aren't exactly ideal.)
As I see it the idiomatic C++ view of what should be deemed an
exception corresponds to what in the Java world is an Error or a
Runtime exception - ie a should-not-happen that no sane person would
want to deal with explicitly, so that in both languages one usually
avoids writing an exception spec for these. Java then extends the
notion to all sorts of other situations that are not really
"exceptional" - eg FileNotFound - for which it makes an exception
specification mandatory. C++ libraries typically choose to deal with
this last category via non-exception means (checking a status field for
example). The Java way is appropriate for a language that doesn't
really trust the programmer not to screw up. The C++ way is appropriate
for a language that credits the programmer with more intelligence than
is sometimes warranted. But the point is that both approaches are
different but appropriate to the languages' intended constituencies.

Sep 26 '06 #29
On Tue, 26 Sep 2006 15:57:25 +0100, "Stuart Golodetz"
<sg*******@dNiOaSl.PpAiMpPeLxE.AcSoEmwrote:
>"Jens Theisen" <jt***@arcor.dewrote in message
>In what way do provide exception specifications more than catch
blocks?
....
>So what's good about them?

As implemented, not much, as far as I can see. I think that's the conclusion
to draw, unfortunately.
You can programmatically control what type of exception is thrown from
your function with simple try/catch/catch(...) blocks within you
function. You are not helplessly at the mercy of low level or third
party functions. How do you come to your strange conclusion?

Best regards,
Roland Pibinger
Sep 26 '06 #30
"Roland Pibinger" <rp*****@yahoo.comwrote in message
news:45**************@news.utanet.at...
On Tue, 26 Sep 2006 15:57:25 +0100, "Stuart Golodetz"
<sg*******@dNiOaSl.PpAiMpPeLxE.AcSoEmwrote:
>>"Jens Theisen" <jt***@arcor.dewrote in message
>>In what way do provide exception specifications more than catch
blocks?
...
>>So what's good about them?

As implemented, not much, as far as I can see. I think that's the
conclusion
to draw, unfortunately.

You can programmatically control what type of exception is thrown from
your function with simple try/catch/catch(...) blocks within you
function. You are not helplessly at the mercy of low level or third
party functions. How do you come to your strange conclusion?

Best regards,
Roland Pibinger
Well, for one thing: suppose said third-party function has its own exception
specification and fails to abide by it (the person writing it slipped up,
maybe it got changed by someone else who wasn't paying careful enough
attention, etc.). At that point, whenever it throws something not in the
specification, std::unexpected() will get called. As a client of the
third-party function, there's nothing you can do about it. Wrapping it in a
try block etc. won't help. You can't work around the problem.

Regards,
Stu
Sep 26 '06 #31
rp*****@yahoo.com (Roland Pibinger) writes:
You can programmatically control what type of exception is thrown from
your function with simple try/catch/catch(...) blocks within you
function. You are not helplessly at the mercy of low level or third
party functions. How do you come to your strange conclusion?
If you could make a proper example of how they do something good that
couldn't be done with catch blocks, posting such would help
understanding. I don't know what you're getting at.

Regards,

Jens
Sep 26 '06 #32
On Tue, 26 Sep 2006 20:19:47 +0100, "Stuart Golodetz"
<sg*******@dNiOaSl.PpAiMpPeLxE.AcSoEmwrote:
>Well, for one thing: suppose said third-party function has its own exception
specification and fails to abide by it (the person writing it slipped up,
maybe it got changed by someone else who wasn't paying careful enough
attention, etc.).
If the third-party function breaks the contract with you it's their
fault.
>At that point, whenever it throws something not in the
specification, std::unexpected() will get called. As a client of the
third-party function, there's nothing you can do about it. Wrapping it in a
try block etc. won't help. You can't work around the problem.
A third party library has a bug. That's pretty normal. Due to
exception specifications it's clear who is to blame.

Best regards,
Roland Pibinger
Sep 26 '06 #33
"Roland Pibinger" <rp*****@yahoo.comwrote in message
news:45***************@news.utanet.at...
On Tue, 26 Sep 2006 20:19:47 +0100, "Stuart Golodetz"
<sg*******@dNiOaSl.PpAiMpPeLxE.AcSoEmwrote:
>>Well, for one thing: suppose said third-party function has its own
exception
specification and fails to abide by it (the person writing it slipped up,
maybe it got changed by someone else who wasn't paying careful enough
attention, etc.).

If the third-party function breaks the contract with you it's their
fault.
>>At that point, whenever it throws something not in the
specification, std::unexpected() will get called. As a client of the
third-party function, there's nothing you can do about it. Wrapping it in
a
try block etc. won't help. You can't work around the problem.

A third party library has a bug. That's pretty normal. Due to
exception specifications it's clear who is to blame.

Best regards,
Roland Pibinger
Allocating blame isn't everything. Well, it might be 99% of everything,
perhaps... :) But seriously, sometimes you just want the damn thing to work.
Telling everyone "We're sorry our program doesn't work - it's *their* fault"
isn't always what you're after.

Stu
Sep 26 '06 #34
Stuart Golodetz wrote:
>
Well, for one thing: suppose said third-party function has its own exception
specification and fails to abide by it (the person writing it slipped up,
maybe it got changed by someone else who wasn't paying careful enough
attention, etc.). At that point, whenever it throws something not in the
specification, std::unexpected() will get called. As a client of the
third-party function, there's nothing you can do about it. Wrapping it in a
try block etc. won't help. You can't work around the problem.
You work around it by installing your own unexpected handler, which
throws an exception that satisfies the throw specifier.

--

-- Pete

Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.
Sep 26 '06 #35
On Tue, 26 Sep 2006 21:17:57 +0100, "Stuart Golodetz"
<sg*******@dNiOaSl.PpAiMpPeLxE.AcSoEmwrote:
>Allocating blame isn't everything. Well, it might be 99% of everything,
perhaps... :) But seriously, sometimes you just want the damn thing to work.
Telling everyone "We're sorry our program doesn't work - it's *their* fault"
isn't always what you're after.
How do you react when they dereference a NULL pointer or when they run
out of bounds? Why should the violation of an exception specification
be treated differently?

Best regards,
Roland Pibinger
Sep 26 '06 #36
On 26 Sep 2006 20:52:27 +0100, Jens Theisen <jt***@arcor.dewrote:
>If you could make a proper example of how they do something good that
couldn't be done with catch blocks, posting such would help
understanding. I don't know what you're getting at.
There seems to be the misconception that exception specifications will
inevitably crash your application because you cannot (in a larger
application) track which exceptions are thrown in lower level (third
party) functions (and hence unexpected() will be called).
The brute force approach to control which exceptions are thrown is to
wrap function bodies in try/catch blocks. (Before you ask ... No, I
don't think that each and any function should have exception
specifications; see the link to the article by Lippman and LaJoie in
another post.)

struct MyExcept : std::runtime_error {
MyExcept (const char* s): std::runtime_error (s) {}
};
inline void badThirdPartyFun() {
throw "hehe";
}
inline void myFun() throw (MyExcept) {
try {
// ...
badThirdPartyFun();
// ...
} catch (MyExcept& ex) {
throw;
} catch (std::exception& ex) {
throw MyExcept (ex.what());
} catch (...) {
throw MyExcept ("something really wrong");
}
}
int main() {
try {
myFun();
} catch (MyExcept& ex) {
std::cout << ex.what() << std::endl;
}
}

The more elegant solution is a reusable exception filter similar to
what is described here:
http://article.gmane.org/gmane.comp....t.devel/132551

Best wishes,
Roland Pibinger
Sep 26 '06 #37
rp*****@yahoo.com (Roland Pibinger) writes:
There seems to be the misconception that exception specifications will
inevitably crash your application because you cannot (in a larger
application) track which exceptions are thrown in lower level (third
party) functions (and hence unexpected() will be called).
I appreciate that this doesn't have to be the case. I'm just wondering
what value exception specifications can add to simple catch blocks.
inline void myFun() throw (MyExcept) {
try {
// ...
badThirdPartyFun();
// ...
} catch (MyExcept& ex) {
throw;
} catch (std::exception& ex) {
throw MyExcept (ex.what());
} catch (...) {
throw MyExcept ("something really wrong");
}
}
How does this differ from

inline void myFunc() /* throw MyExcept */ try
{
...
} catch(MyExcept const& ex) {
throw;
} catch(std::exception const& ex) {
throw MyExcept (ex.what());
} catch(...) {
throw MyExcept ("something really wrong");
}

?

What does your code provide that mine doesn't?

In can only think of: The documentation might not be in sync with the
proper code; but in that case, the library is buggy in both code
snippets - it's just a call to unexpected in yours and an exception
propagation in mine; I even prefer the latter if the library is buggy
in that way.

None of your cited articles give an answer to this very legitimate
question.

Regards,

Jens
Sep 26 '06 #38
"Pete Becker" <pe********@acm.orgwrote in message
news:V7******************************@giganews.com ...
Stuart Golodetz wrote:
>>
Well, for one thing: suppose said third-party function has its own
exception specification and fails to abide by it (the person writing it
slipped up, maybe it got changed by someone else who wasn't paying
careful enough attention, etc.). At that point, whenever it throws
something not in the specification, std::unexpected() will get called. As
a client of the third-party function, there's nothing you can do about
it. Wrapping it in a try block etc. won't help. You can't work around the
problem.

You work around it by installing your own unexpected handler, which throws
an exception that satisfies the throw specifier.

--

-- Pete

Author of "The Standard C++ Library Extensions: a Tutorial and Reference."
For more information about this book, see www.petebecker.com/tr1book.
Fair enough. Thinking about it, though, presumably if there are two or more
such situations, you'd need to keep changing the unexpected handler?

Stu
Sep 27 '06 #39
"Roland Pibinger" <rp*****@yahoo.comwrote in message
news:45***************@news.utanet.at...
On Tue, 26 Sep 2006 21:17:57 +0100, "Stuart Golodetz"
<sg*******@dNiOaSl.PpAiMpPeLxE.AcSoEmwrote:
>>Allocating blame isn't everything. Well, it might be 99% of everything,
perhaps... :) But seriously, sometimes you just want the damn thing to
work.
Telling everyone "We're sorry our program doesn't work - it's *their*
fault"
isn't always what you're after.

How do you react when they dereference a NULL pointer or when they run
out of bounds? Why should the violation of an exception specification
be treated differently?

Best regards,
Roland Pibinger
You're probably right, it shouldn't :) I'm having one of those "I've got
tangled up in my own argument" moments. I'm still not sure I like the way
exception specifications work in C++ though. Ah well.

Regards,
Stu
Sep 27 '06 #40
Stuart Golodetz wrote:
>
Thinking about it, though, presumably if there are two or more
such situations, you'd need to keep changing the unexpected handler?
The usual idiom (if there is one) is to use a class whose constructor
installs the handler you want and whose destructor restores the previous
handler.

You can also do it with one handler, but it's more complicated. You have
to detect the type that was thrown (by rethrowing the original exception
and catching it by type), then throw the appropriate replacement.

--

-- Pete

Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.
Sep 27 '06 #41
Jens Theisen wrote:
rp*****@yahoo.com (Roland Pibinger) writes:
>There seems to be the misconception that exception specifications will
inevitably crash your application because you cannot (in a larger
application) track which exceptions are thrown in lower level (third
party) functions (and hence unexpected() will be called).

I appreciate that this doesn't have to be the case. I'm just wondering
what value exception specifications can add to simple catch blocks.
The difference is in who manages the problem. try/catch blocks are a
local solution; an unexpected handler is global.

--

-- Pete

Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.
Sep 27 '06 #42

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

6
by: Philipp Holzschneider | last post by:
Are there any available c++ compilers around that strictly implement the mentioned "Exception Specification" feature?? where the following compiles void func() { throw A(); }; void gunc()...
28
by: Scott Brady Drummonds | last post by:
Hi, all, I just got out of a meeting with a team of software developers that I recently joined as they are staffing to create a medium-sized project (potentially all of which will be written in...
10
by: linq936 | last post by:
Hi, I have many assert() call in my code, now I am considering to replace them with exception. The reason I want to do this change is that with the program going bigger and bigger, it is hard to...
6
by: benben | last post by:
Why doesn't the following code work? template <typename ExceptionT> void f(void) throw (ExceptionT) { throw ExceptionT(); } Ben
1
by: Brian | last post by:
I'm trying to comile some managed C++ code in VC++ 2005 beta that has a lot of exception specifications,ie int func() throw( SomeException*) ; I'm getting these messages: error C2353:...
13
by: junw2000 | last post by:
Is C++ Exception handling useful? think it is too complicated. What kinds of project need to use it? Thanks.
11
by: George2 | last post by:
Hello everyone, How do you understand the Bjarne's comments about exception specification? Especially, "not required to be checked across compilation-unit" and "violations will not be caught...
12
by: Ioannis Vranos | last post by:
Perhaps a mechanism can be introduced in the C++0x/1x standard, something simple like defining a function as: void somefunc(void) throw() { // ... }
7
by: Keith Halligan | last post by:
I'm a bit unsure about exception specifications and the rules that they enforce. I've had a look at the C++ spec and it doesn't state about the errors that it enforces, if an exception is thrown...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.