Re: exception
On Feb 17, 3:30 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* James Kanze:
On Feb 17, 6:51 am, "Alf P. Steinbach" <al...@start.no> wrote:
* ramu:
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.
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...
But will they mean anything? If I understand it correctly, a
compiler is allowed to ignore such things.
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.
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.
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.)
"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.
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.)
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.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34