Bjarne's comments about exception specification

[George2]

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 at run time"?

section 14.6.1 Checking Exception Specifications

--------------------
Importantly, exception-specifications are not required to be checked
exactly across compilation-unit boundaries. Naturally, an
implementation could check. However, for many large and long-lived
systems, it is important that the implementation does not -- or, if it
does, than it carefully gives hard errors only where violations will
not be caught at run time.
--------------------
thanks in advance,
George

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2008-01-20 11:26, Alf P. Steinbach wrote:

* George2:

>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 at run time"?

section 14.6.1 Checking Exception Specifications

--------------------
Importantly, exception-specifications are not required to be checked
exactly across compilation-unit boundaries. Naturally, an
implementation could check. However, for many large and long-lived
systems, it is important that the implementation does not -- or, if it
does, than it carefully gives hard errors only where violations will
not be caught at run time.
--------------------

I wonder where you found that and how old it is.

If it refers to C++ then it's incorrect per the current standard (1998),
and was also incorrect with respect to the 1991 ARM.

It is in the 3rd ed. of TC++PL, but it is taken out of context. I think
he is referring to whether the compiler will give any warnings/errors at
compile-time (though I can not find any mentioning of this in the standard).

Section 14.6.1 starts by talking about checking of exception-
specifications at compile-time and the paragraph after the quoted one
says that the point is that you should not have to go through all your
code and update your exception-specifications just because you make some
change that allows more exceptions to be thrown.

--
Erik Wikström

[Ioannis Vranos]

Does anyone use exception specifications in real world? I think they are
difficult to keep complying with them after some time, and are difficult
to be always accurate when defining them.

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2008-01-20 13:26, Ioannis Vranos wrote:

Does anyone use exception specifications in real world? I think they are
difficult to keep complying with them after some time, and are difficult
to be always accurate when defining them.

The empty specification (throw()) is quite useful to indicate that a
function does not throw (can be good to know when dealing with exception
safety). But other than that I do not see any widespread use of it.

--
Erik Wikström

[Ioannis Vranos]

Erik Wikström wrote:

On 2008-01-20 13:26, Ioannis Vranos wrote:

>Does anyone use exception specifications in real world? I think they are
difficult to keep complying with them after some time, and are difficult
to be always accurate when defining them.

The empty specification (throw()) is quite useful to indicate that a
function does not throw (can be good to know when dealing with exception
safety). But other than that I do not see any widespread use of it.

Perhaps a mechanism could be introduced in the C++0x/1x standard,
something simple like defining a function as:
void somefunc(void) throw()
{
// ...
}
and getting a compile time error saying something like:
"Error: void somefunc(void) throw(): Wrong exception specification.
somefunc can throw std::bad_alloc, std::range_error".

That is make the compiler to check exception specifications for errors too.

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2008-01-20 17:45, Ioannis Vranos wrote:

Erik Wikström wrote:

>On 2008-01-20 13:26, Ioannis Vranos wrote:

>>Does anyone use exception specifications in real world? I think they are
difficult to keep complying with them after some time, and are difficult
to be always accurate when defining them.

The empty specification (throw()) is quite useful to indicate that a
function does not throw (can be good to know when dealing with exception
safety). But other than that I do not see any widespread use of it.

Perhaps a mechanism could be introduced in the C++0x/1x standard,
something simple like defining a function as:
void somefunc(void) throw()
{
// ...
}
and getting a compile time error saying something like:
"Error: void somefunc(void) throw(): Wrong exception specification.
somefunc can throw std::bad_alloc, std::range_error".

That is make the compiler to check exception specifications for errors too.

Could be, but it would probably not work as well as you want. I am not
sure that it would work when calling functions that you do not have the
source for (i.e. there is not information about what exceptions can be
thrown in the binary).

--
Erik Wikström

[Ioannis Vranos]

Erik Wikström wrote:

somefunc can throw std::bad_alloc, std::range_error".

>>
That is make the compiler to check exception specifications for errors too.

Could be, but it would probably not work as well as you want. I am not
sure that it would work when calling functions that you do not have the
source for (i.e. there is not information about what exceptions can be
thrown in the binary).

Well, I suppose it could work for the source we have, in few words the
exception safety would be increased. An existing pre-built C++ library
could be revised to provide exception specifications at its next
release. That is, in the future the total exception safety would
increase, because the exception specification mechanism would finally
work (since now it doesn't work in practice as it is).

[James Kanze]

On Jan 20, 12:39 pm, Erik Wikström <[e-mail]:

[...]

Section 14.6.1 [of TC++PL] starts by talking about checking of
exception- specifications at compile-time and the paragraph
after the quoted one says that the point is that you should
not have to go through all your code and update your
exception-specifications just because you make some change
that allows more exceptions to be thrown.

Except that you have to do that anyway. If a function
guarantees that it will not throw any exceptions, or that it
will only throw X, then if it is changed to throw Y, the
contract has been changed, and all call sites must be
re-evaluated with respect to the new contract.

Realistically, of course, there's usually no point in
restricting which exceptions might be thrown by contract, at
least in most cases. So it would really only be relevant for
throw(). And realistically, there is a lot of code out there
which doesn't throw, and isn't declared throw(), so you
introducing compile time errors at this late date would only
break most existing code. (Note that when exceptions were
introduced into the language, none of the existing functions
threw, and none had an exception specification either.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Bo Persson]

Ioannis Vranos wrote:

Erik Wikström wrote:

>On 2008-01-20 13:26, Ioannis Vranos wrote:

>>Does anyone use exception specifications in real world? I think
they are difficult to keep complying with them after some time,
and are difficult to be always accurate when defining them.

The empty specification (throw()) is quite useful to indicate that
a function does not throw (can be good to know when dealing with
exception safety). But other than that I do not see any widespread
use of it.

Perhaps a mechanism could be introduced in the C++0x/1x standard,
something simple like defining a function as:
void somefunc(void) throw()
{
// ...
}
and getting a compile time error saying something like:
"Error: void somefunc(void) throw(): Wrong exception specification.
somefunc can throw std::bad_alloc, std::range_error".

That is make the compiler to check exception specifications for
errors too.

Yes, but you would get into real trouble if somefunc() calls some
templated functions, where one or two specializations might throw. How
is the compiler to know?
Bo Persson

[Ioannis Vranos]

Ioannis Vranos wrote:

>
Perhaps a mechanism could be introduced in the C++0x/1x standard,
something simple like defining a function as:
void somefunc(void) throw()
{
// ...
}
and getting a compile time error saying something like:
"Error: void somefunc(void) throw(): Wrong exception specification.
somefunc can throw std::bad_alloc, std::range_error".

That is make the compiler to check exception specifications for errors too.

Some more details:
What I have in mind is "loose" application. That is, the compiler should
check only the available code accessible to it.
In addition, I think throw(void) should be equivalent to throw(), and
throw(...) should be equivalent to non-throw specification, e.g.:
// May throw anything.
void somefunc()
{
// ...
}
// May throw anything.
void somefunc() throw(...)
{
// ...
}
I think that even loose, the compile time checking of throw
specifications will improve the overall exception safety, and everyone
will usually know the exact types of exceptions he can catch on a given
call.
Any existing third-party, pre-built C++ library can be revised to
provide exception specifications at its next release. That is, in the
future the total exception safety will increase, because the exception
specification mechanism will finally work (since now I think it doesn't
work as it is provided, in practice).

Or that library can keep providing its facilities without exception
specifications or with the throw(...) equivalent ones.
If I may repeat, what I have in mind is "loose" application. That is,
the compiler should check only the available code accessible to it.
In the case of some function having the throw() specification, is using
indirectly code that may throw some exception, it can be flagged as a
compile-time error, provided that this source code that is used
indirectly by this function, is accessible to the compiler. Otherwise,
it will not be flagged as a compile-time error.

The run-time stuff of the throw specifications will still apply.

[Ioannis Vranos]

Ioannis Vranos wrote:

Ioannis Vranos wrote:

>>
Perhaps a mechanism could be introduced in the C++0x/1x standard,
something simple like defining a function as:
void somefunc(void) throw()
{
// ...
}
and getting a compile time error saying something like:
"Error: void somefunc(void) throw(): Wrong exception specification.
somefunc can throw std::bad_alloc, std::range_error".

That is make the compiler to check exception specifications for errors
too.

Some more details:
What I have in mind is "loose" application. That is, the compiler should
check only the available code accessible to it.
In addition, I think throw(void) should be equivalent to throw(), and
throw(...) should be equivalent to non-throw specification, e.g.:
// May throw anything.
void somefunc()
{
// ...
}
// May throw anything.
void somefunc() throw(...)
{
// ...
}
I think that even loose, the compile time checking of throw
specifications will improve the overall exception safety, and everyone
will usually know the exact types of exceptions he can catch on a given
call.
Any existing third-party, pre-built C++ library can be revised to
provide exception specifications at its next release. That is, in the
future the total exception safety will increase, because the exception
specification mechanism will finally work (since now I think it doesn't
work as it is provided, in practice).

Or that library can keep providing its facilities without exception
specifications or with the throw(...) equivalent ones.
If I may repeat, what I have in mind is "loose" application. That is,
the compiler should check only the available code accessible to it.
In the case of some function having the throw() specification, is using
indirectly code that may throw some exception, it can be flagged as a
compile-time error, provided that this source code that is used
indirectly by this function, is accessible to the compiler. Otherwise,
it will not be flagged as a compile-time error.

The run-time stuff of the throw specifications will still apply.

Addition 2:

In this proposal, I think an opposite of the throw keyword may be
needed, to specify the exceptions that the compiler will ignore. I think
the right place of it, is the end of the function scope. An example:
void somefunc() throw()
{
std::vector<intvec;

// ...

} nothrow(std::out_of_range)

[Ioannis Vranos]

Ioannis Vranos wrote:

Ioannis Vranos wrote:

>Ioannis Vranos wrote:

>>>
Perhaps a mechanism could be introduced in the C++0x/1x standard,
something simple like defining a function as:
void somefunc(void) throw()
{
// ...
}
and getting a compile time error saying something like:
"Error: void somefunc(void) throw(): Wrong exception specification.
somefunc can throw std::bad_alloc, std::range_error".

That is make the compiler to check exception specifications for
errors too.

Some more details:
What I have in mind is "loose" application. That is, the compiler
should check only the available code accessible to it.
In addition, I think throw(void) should be equivalent to throw(), and
throw(...) should be equivalent to non-throw specification, e.g.:
// May throw anything.
void somefunc()
{
// ...
}
// May throw anything.
void somefunc() throw(...)
{
// ...
}
I think that even loose, the compile time checking of throw
specifications will improve the overall exception safety, and everyone
will usually know the exact types of exceptions he can catch on a
given call.
Any existing third-party, pre-built C++ library can be revised to
provide exception specifications at its next release. That is, in the
future the total exception safety will increase, because the exception
specification mechanism will finally work (since now I think it
doesn't work as it is provided, in practice).

Or that library can keep providing its facilities without exception
specifications or with the throw(...) equivalent ones.
If I may repeat, what I have in mind is "loose" application. That is,
the compiler should check only the available code accessible to it.
In the case of some function having the throw() specification, is
using indirectly code that may throw some exception, it can be flagged
as a compile-time error, provided that this source code that is used
indirectly by this function, is accessible to the compiler. Otherwise,
it will not be flagged as a compile-time error.

The run-time stuff of the throw specifications will still apply.

Addition 2:

In this proposal, I think an opposite of the throw keyword may be
needed, to specify the exceptions that the compiler will ignore. I think
the right place of it, is the end of the function scope. An example:
void somefunc() throw()
{
std::vector<intvec;

// ...

} nothrow(std::out_of_range)

Some examples of these:
I.

void somefunc() throw(std::bad_alloc, my_app::graph_range_error)
{
// ...
} nothrow(std::out_of_range)

II. Equivalent cases:

void somefunc() throw()
{
// ...
} nothrow(std::bad_alloc)
void somefunc() throw(void)
{
// ...
} nothrow(std::bad_alloc)

III. Equivalent cases:

void somefunc()
{
// ...
}

void somefunc() throw(...)
{
// ...
}

void somefunc() throw(...)
{
// ...
} nothrow()
void somefunc()
{
//...
} nothrow()
void somefunc() throw(...)
{
// ...
} nothrow(void)
void somefunc()
{
//...
} nothrow(void)