By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,272 Members | 1,272 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,272 IT Pros & Developers. It's quick & easy.

templated exception type

P: n/a
Why doesn't the following code work?

template <typename ExceptionT>
void f(void) throw (ExceptionT)
{
throw ExceptionT();
}

Ben
Sep 16 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
"benben" <moc.liamtoh@hgnohneb read backward> wrote in message
news:43***********************@news.optusnet.com.a u...
Why doesn't the following code work?

template <typename ExceptionT>
void f(void) throw (ExceptionT)
{
throw ExceptionT();
}

Ben


What goes wrong?

--
Cy
http://home.rochester.rr.com/cyhome/
Sep 17 '05 #2

P: n/a

benben wrote:
Why doesn't the following code work?

template <typename ExceptionT>
void f(void) throw (ExceptionT)
{
throw ExceptionT();
}

Ben


Well, what does this compile as when ExceptionT is defined...

void f() throw (MyClass)
{
throw MyClass();
}

That doesn't look like valid syntax to me. You cannot throw outside of
a function body.

try...
template <typename ExceptionT>
void f(void)
{
throw ExceptionT();
}

Sep 17 '05 #3

P: n/a
* John Fullman:
* benben:

Why doesn't the following code work?

template <typename ExceptionT>
void f(void) throw (ExceptionT)
{
throw ExceptionT();
}
Well, what does this compile as when ExceptionT is defined...

void f() throw (MyClass)
{
throw MyClass();
}

That doesn't look like valid syntax to me.


It is.

You cannot throw outside of a function body.


You can, but that is another kettle of cats (uh). The above 'throw (MyClass)'
is an exception specification, not an exception throw statement.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Sep 17 '05 #4

P: n/a

Alf P. Steinbach wrote:

You can, but that is another kettle of cats (uh). The above 'throw (MyClass)'
is an exception specification, not an exception throw statement.


really??? I have never seen that syntax my years of C++...
Shows how much I know :p

MSDN says...
Exception specifications are used to provide summary information about
what exceptions can be thrown out of a function.

What does a statement like this do in terms of compiled code? Or is
this syntax just for the programmer that is using the .h file?

Sep 17 '05 #5

P: n/a
* John Fullman:

What does a statement like this do in terms of compiled code?
You mean, a function declaration like

void foo() throw( T, U, V );

With a conforming compiler it adds a check that no exception that isn't a T or
U or V (etc.) or derived class is thrown out of the function. If that is
violated then std::unexpected() is called. By default that function in turn
calls std::terminate, but you have the option of installing your own version
that instead throws a new exception, one permitted by foo's specification --
which in practice there's no way to know...

However, if std::unexpected throws an exception not permitted by foo's
specification, but that specification includes std::bad_exception (the
standard, in 15.5.2/2, doesn't specify whether that means explicitly includes
or implicitly includes via the base class std::exception), then the new
exception is automatically replaced by a std::bad_exception; otherwise, when
the new exception is not permitted by foo and std::bad_exception is not
included in the specification, std::terminate is called.

So if possible the new exception, if any, should preferentially be a
std::bad_exception, so that it's possible to know what to expect.

Summing up, exception specifications are complicated (two levels of automated
actions with a possible user-defined one added in the middle), the effect is
partially undefined (see above), and it's a nightmare to maintain exception
specifications in a larger program, as Java programmers well know.

Consequently, exception specifications, except empty specifications (no-
throw), are seldom used in real-world C++ programming. It's much the same as
with template "export", a compromise feature introduced by the standardization
committee. Neither feature formalized existing practice, and both features,
in their compromise forms, turned out to have negative worth in practice.

MSVC is one compiler that simply doesn't support these two features, other
than syntactically.

Or is this syntax just for the programmer that is using the .h file?


No.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Sep 17 '05 #6

P: n/a
John Fullman wrote:
Alf P. Steinbach wrote:

You can, but that is another kettle of cats (uh). The above 'throw (MyClass)'
is an exception specification, not an exception throw statement.


really??? I have never seen that syntax my years of C++...
Shows how much I know :p

MSDN says...
Exception specifications are used to provide summary information about
what exceptions can be thrown out of a function.

What does a statement like this do in terms of compiled code? Or is
this syntax just for the programmer that is using the .h file?


The basic flaw with C++'s exception specification is that it specifies
a runtime and not a compile time constraint on the program. I think
that most programmers when first learning about exception
specifications would assume that the compiler (and the linker as well)
checked that a function with an exception specification does not itself
throw - or call another function that could throw - an exception not
allowed by its specification. Such behavior would be useful, not only
for the potential to reduce the size of compiled code, but also to help
implement "no fail" guarantees for certain types of operations.

As it stands, the specification takes effect at runtime, when it is far
too late to correct any errors in an routine's exception specification.
Worse yet, the consequence of such errors - essentially to terminate
the app - is too drastic an outcome for most programmers to risk -
especially in a release build running on a customer's machine. It also
doesn't help that this risk is largely unnecessary and could have been
eliminated had the compiler verified the exception specifications at
the time that the code was compiled.

Greg

Sep 18 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.