Exception Specifications

[Stuart Golodetz]

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

[Julián Albo]

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

[Stuart Golodetz]

"Julián Albo" <JU********@ter ra.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

[peter koch]

Stuart Golodetz skrev:

"Julián Albo" <JU********@ter ra.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<int v;
.....

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

[Julián Albo]

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

[Julián Albo]

peter koch wrote:

I believe it is hard. Consider:

std::vector<int v;
....

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

[Jens Theisen]

"Stuart Golodetz" <sg*******@dNiO aSl.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

[Bo Persson]

Julián Albo wrote:

peter koch wrote:

>I believe it is hard. Consider:

std::vector<in tv;
....

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

[Julián Albo]

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

[Jerry Coffin]

In article <AL************ ********@pipex. net>,
sg*******@dNiOa Sl.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.