exception

[ramu]

Hi,
Can anybody tell how to restrict a function from throwing any
exception?

Regards.

 

[Alf P. Steinbach]

* ramu:

Hi,
Can anybody tell how to restrict a function from throwing any
exception?

With a standard-conforming compiler you can achieve essentially that by giving
the routine an empty throw specification, e.g.

void foo() throw() { }

But this isn't a compile time restriction, it's a run time restriction. In fact
the standard guarantees that even if foo very clearly throws some exception, the
code will be accepted. If foo throws, the effect is then to cause a call of the
current 'unexpected' handler, which by default terminates the program.

Not all compilers / compiler versions implement this scheme, though: an
exception specification may just be ignored by your compiler.

If so then you can achieve essentially the same yourself by defining a wrapper
routine. E.g.,

void foo() { }

void foo_nothrow()
{
try { foo(); } catch( ... ) { std::terminate(); }
}

And except for the on-exception action this also illustrates what the compiler
has to generate code to do when you equip some routine with an empty throw
specification.


Cheers & hth.,

- Alf

 

[James Kanze]

* ramu:

With a standard-conforming compiler you can achieve
essentially that by giving the routine an empty throw
specification, e.g.

void foo() throw() { }

But this isn't a compile time restriction, it's a run time
restriction.

Which makes sense, sort of, because throwing an exception is a
runtime action, and it's impossible in the general case to know
whether a function will throw an exception or not. Consider:

extern sqrt( double x ) throw ( math_error ) ;
// only if x < 0.0...

double
f() throw()
{
return sqrt( 2.0 ) ;
}

How is the compiler to know that this function can't throw.

And FWIW: I'm repeating the "official" argument here.
Personally, I'd rather see static checking, even if it meant
that the implementer had to write that last function as:

doubld
f() throw()
{
try {
return sqrt( 2.0 ) ;
} catch ( ... ) {
abort() ;
}

But my views don't hold that much weight in the standard's
committee.

In fact the standard guarantees that even if foo very clearly
throws some exception, the code will be accepted. If foo
throws, the effect is then to cause a call of the current
'unexpected' handler, which by default terminates the program.

That's sort of a misrepresentation. It's like saying that the
standard guarantees that:

void
f()
{
assert( 1 == 0 ) ;
}

has to be accepted. It's true, but that's not the point.

Not all compilers / compiler versions implement this scheme,
though: an exception specification may just be ignored by your
compiler.

You might also point out that writing reliable exception safe
code isn't possible with such a compiler. For a GUI front end
which is only concerned with presentation, no big deal, but I
wouldn't use such a compiler on a mission critical server. (Of
course, the compiler in question doesn't support any platforms
that anyone would use for mission critical servers, so perhaps
it isn't that bad. No matter what precautions you take, your
software will never be more robust than the platform you run
on.)

If so then you can achieve essentially the same yourself by
defining a wrapper routine. E.g.,

void foo() { }

void foo_nothrow()
{
try { foo(); } catch( ... ) { std::terminate(); }
}

And except for the on-exception action this also illustrates
what the compiler has to generate code to do when you equip
some routine with an empty throw specification.

Almost. It's behavior is significantly different if you replace
the standard std::terminate with one which throws an exception.
(To which I would respond: don't do it.)

 

[Alf P. Steinbach]

* James Kanze:

Which makes sense, sort of, because throwing an exception is a
runtime action, and it's impossible in the general case to know
whether a function will throw an exception or not. Consider:

extern sqrt( double x ) throw ( math_error ) ;
// only if x < 0.0...

double
f() throw()
{
return sqrt( 2.0 ) ;
}

How is the compiler to know that this function can't throw.

And FWIW: I'm repeating the "official" argument here.
Personally, I'd rather see static checking, even if it meant
that the implementer had to write that last function as:

doubld
f() throw()
{
try {
return sqrt( 2.0 ) ;
} catch ( ... ) {
abort() ;
}

But my views don't hold that much weight in the standard's
committee.

Perhaps we'll get a [[nothrow]] along with [[noreturn]] in v2 of C++0x...

That's sort of a misrepresentation. It's like saying that the
standard guarantees that:

void
f()
{
assert( 1 == 0 ) ;
}

has to be accepted. It's true, but that's not the point.

Now /that's/ a sort of misrepresentation: it's true, but is not the point.

For a throw specification there is a difference between what you would have with
static versus dynamic checking.

And my paragraph explained that difference: that with respect to this a
conforming compiler isn't even allowed to use knowledge of what must happen at
run time to reject some code, absolutely no static check of actual throwing.

You might also point out that writing reliable exception safe
code isn't possible with such a compiler. For a GUI front end
which is only concerned with presentation, no big deal, but I
wouldn't use such a compiler on a mission critical server. (Of
course, the compiler in question doesn't support any platforms
that anyone would use for mission critical servers, so perhaps
it isn't that bad. No matter what precautions you take, your
software will never be more robust than the platform you run
on.)

"Isn't possible" requires just one counter-example...

And in the case of the compiler I think you're referring to, namely MSVC in
Windows, well it's one of the most popular compilers.

In addition to that abundance of counter-examples, I pointed out, quoted below,
how mostly the same effect can be achieved manually, without language support.
What's lacking is only checking of compatibility of exception specifications for
overrides of a virtual routine. And that's really not an issue in practice.

Almost. It's behavior is significantly different if you replace
the standard std::terminate with one which throws an exception.
(To which I would respond: don't do it.)

Isn't that covered by "except for the on-exception action"?

Replace 'std::terminate();" with some "__call_unexpected();" and that's it.


Cheers,

- Alf

 

[James Kanze]

* James Kanze:

Perhaps we'll get a [[nothrow]] along with [[noreturn]] in v2
of C++0x...

But will they mean anything? If I understand it correctly, a
compiler is allowed to ignore such things.

Now /that's/ a sort of misrepresentation: it's true, but is
not the point.

For a throw specification there is a difference between what
you would have with static versus dynamic checking.

With assert, there could be, too, in some cases. And as I
pointed out, the compiler cannot guarantee correct static
checking in all cases.

And my paragraph explained that difference: that with respect
to this a conforming compiler isn't even allowed to use
knowledge of what must happen at run time to reject some code,
absolutely no static check of actual throwing.

A conforming compiler can use the knowledge in the same way it
can use the knowledge from an assert. The only real differences
are 1) you can't replace the assert handler, and 2) there's no
way to hoist an assert up into the function declaration, so that
a compiler which only sees the declaration can do something with
it. (As an example of what I mean:

void
f( char const* p )
{
assert( p != NULL ) ;
}

and then in client code:

f( NULL ) ;

Unless the compiler can see the full implementation of the
function, there's no way it can warn about the obvious error.
Or given
f( p ) ;
there's no way it can know that if we return from f, p cannot be
null (which can lead to some other optimizations). When we
specify:
void f( char const* ) throw() ;
however, the compiler can know that the call to f will not
return via an exception. So, for example, it doesn't have to
synchronize local variables (which might be references somehow
from a destructor) with memory.

"Isn't possible" requires just one counter-example...

And in the case of the compiler I think you're referring to,
namely MSVC in Windows, well it's one of the most popular
compilers.

Certainly, but for what types of applications. All of the
mission critical stuff I know runs on commercial Unix. There's
a lot of experimentation with Linux at present, but for the
moment, it's not really stable enough to trust it with mission
critical software.

And of course, there are always companies that don't understand
risk management, and sometimes they luck out.

In addition to that abundance of counter-examples, I pointed
out, quoted below, how mostly the same effect can be achieved
manually, without language support. What's lacking is only
checking of compatibility of exception specifications for
overrides of a virtual routine. And that's really not an issue
in practice.

Isn't that covered by "except for the on-exception action"?

Ah. To tell the truth, I wasn't sure what you meant by that.