throwable .vs. non throwable?

[Jim Langston]

I have a template I use for converting types:

template<typename T, typename F T StrmConvert( const F from )
{
std::stringstream temp;
temp << from;
T to = T();
temp >to;
return to;
}

template<typename Fstd::string StrmConvert( const F from )
{
return StrmConvert<std::string>( from );
}

As you can see, it doesn't throw. If the conversion can not take place,
then it simply returns a default constructed type, which is fine for most
cases I use it. However, there may be a case where I want to throw on error.
I know I could simply copy this template and give it a new name, such as
StrmConvertThrow but I don't like that solution. What I would like to be
able to do (which may not be possible) is something like:

int i = 10;
std::string x;

x = StrmConvert( i ):throwable;

or such. I don't think that's right, well, okay, I know it's not right. I
do know that there is a throw( int ) type keyword for functions. I tried to
duplicate StrmConvert like this:

template<typename T, typename F T StrmConvert( const F from ) throw(
int )

but got compile time errors.

console5.cpp(17) : warning C4290: C++ exception specification ignored except
to indicate a function is not __declspec(nothrow)
console5.cpp(24) : error C2382: 'StrmConvert' : redefinition; different
exception specifications
console5.cpp(3) : see declaration of 'StrmConvert'

so apparently C++ doesn't distinguish between function signatures by throw
or not. Although I seem to recall something about there being a new, and a
new throwable.

Am I barking up the wrong tree, or is there a way to do what I want?

[Roland Pibinger]

On Mon, 23 Jul 2007 18:39:27 -0700, "Jim Langston" wrote:

>I have a template I use for converting types:

template<typename T, typename F T StrmConvert( const F from )
{
std::stringstream temp;
temp << from;
T to = T();
temp >to;
return to;
}

template<typename Fstd::string StrmConvert( const F from )
{
return StrmConvert<std::string>( from );
}

As you can see, it doesn't throw.

Each statement in your code may throw an exception.

>If the conversion can not take place,
then it simply returns a default constructed type,

Maybe, maybe not. You cannot forsee this for any type T.

>which is fine for most
cases I use it. However, there may be a case where I want to throw on error.
I know I could simply copy this template and give it a new name, such as
StrmConvertThrow but I don't like that solution. What I would like to be
able to do (which may not be possible) is something like:

You misunderstood exception specifications in C++. In general,
templates and exception specifications don't blend.
--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch

[James Kanze]

On Jul 24, 3:39 am, "Jim Langston" <[e-mail]:

I have a template I use for converting types:

template<typename T, typename F T StrmConvert( const F from )
{
std::stringstream temp;
temp << from;
T to = T();
temp >to;
return to;
}

template<typename Fstd::string StrmConvert( const F from )
{
return StrmConvert<std::string>( from );
}

As you can see, it doesn't throw.

I don't see that. On my system, it certainly throws in certain
cases. (If you've not exercised this code enough to see a
bad_alloc exception, then you've not tested it enough.)

If the conversion can not take place,
then it simply returns a default constructed type, which is fine for most
cases I use it. However, there may be a case where I want to throw on error.
I know I could simply copy this template and give it a new name, such as
StrmConvertThrow but I don't like that solution. What I would like to be
able to do (which may not be possible) is something like:

int i = 10;
std::string x;

x = StrmConvert( i ):throwable;

or such.

There's no way. Whether a function can throw or not is not
considered in overload resolution, and there's no way for you to
specify that you want a version that doesn't throw, or that
does.

The obvious solution is to make the throwing behavior the
default, and to write something like:

T myT ;
try {
myT = StrmConvert( i ) ;
} catch ( ... ) {
}

in the case where you don't care (which should be extremely rare
in most applications).

I don't think that's right, well, okay, I know it's not right. I
do know that there is a throw( int ) type keyword for functions.

That's an exception specification. The unique example of
programming by contract in the current language---it expresses a
contract, saying that this function will not throw anything
else, and if the function violates the contract, it terminates
the program. (Sort of like assert(), really.)

I tried to duplicate StrmConvert like this:

template<typename T, typename F T StrmConvert( const F from ) throw(
int )

but got compile time errors.

console5.cpp(17) : warning C4290: C++ exception specification ignored except
to indicate a function is not __declspec(nothrow)
console5.cpp(24) : error C2382: 'StrmConvert' : redefinition; different
exception specifications
console5.cpp(3) : see declaration of 'StrmConvert'

so apparently C++ doesn't distinguish between function
signatures by throw or not.

The exception specification is not part of the function
signature. No more than an assert in the body would be.

Although I seem to recall something about there being a new,
and a new throwable.

That's a completely different issue. Normally, new notifies the
lack of memory by throwing std::bad_alloc. If the user wants to
get a null pointer instead, he can use a placement new with a
no_throw additional parameter, and new will return null, rather
than throwing, if there is not enough memory.

Am I barking up the wrong tree, or is there a way to do what I
want?

My immediate reaction would be to avoid this sort of function to
begin with.

--
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]

[Jim Langston]

"James Kanze" <ja*********@gmail.comwrote in message
news:11**********************@m3g2000hsh.googlegro ups.com...
On Jul 24, 3:39 am, "Jim Langston" <[e-mail]:
[SNIP good replies]

Although I seem to recall something about there being a new,
and a new throwable.

That's a completely different issue. Normally, new notifies the
lack of memory by throwing std::bad_alloc. If the user wants to
get a null pointer instead, he can use a placement new with a
no_throw additional parameter, and new will return null, rather
than throwing, if there is not enough memory.

I think I'll take a look at the no_throw additional parameter, and attempt
to add it to StrmConvert. If that's the way placement new does it, then
maybe I should emulate it. Although it's most likely some enum or define,
I'd like to use something relatively standard.

Am I barking up the wrong tree, or is there a way to do what I
want?

My immediate reaction would be to avoid this sort of function to
begin with.

Well, this code was orignally designed for simple ouput without having to
build stringstream in my mainline.

I've since gone to using it for user input via sockets and there are many
times it is perfectly acceptable to allow default constructed values. In
fact, there hasn't been a case yet where it would cause my program to crash
if it wasn't. I parse out the fields and do any rudementary checking before
I pass them to StrmConvert. It is actually the rare occasion I want to know
if it didn't convert correctly (in fact, there hasn't been a case yet, but
I'm building for the future).

For other code I may work on in the future, I may want it to throw, which is
why I'm looking at the best way to do it.

[Jerry Coffin]

In article <11*********************@o61g2000hsh.googlegroups. com>,
ja*********@gmail.com says...

[ ... ]

In addition to my other comments, it just occurs to me that
there is one (admittedly very special) case where they are
almost necessary. If you write a placement operator new
function which returns a null pointer if it cannot fulfill the
request, you must give it an empty exception specification.
Without an empty exception specification, the compiler is free
to assume that the function will never return a null pointer,
and generate code like:

Okay -- that's an example I can agree with. While obscure, it's real,
and I can see where leaving out the exception specification honestly
causes a problem.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Jerry Coffin]

In article <46**************@news.utanet.at>, rp*****@yahoo.com says...

[ ... ]

class DataBase {
// ...
Connection* getConnection (...) throw (SQLException);
};

This lacks the detail necessary to evaluate it, but on the face of it
looks like precisely the sort of situation I'd have used as an example
of them being harmful.

I was strongly in favor of
exception specifications until I really tried to use them. I even used
them sometimes for a while -- but I've yet to see a single situation
where they really accomplish anything useful.

They are part of the contract between implementor and user. In this
respect they are very useful.

Once again: a bald assertion that they're useful doesn't cut it. You
need to provide a real example -- and by a real example, I mean enough
code that I (or whoever reads it) can analyze the code and the
situation, and be shown how and why the code benefits from the exception
specification. Right now you've basically just taken "ret_type func_name
(args) throw(exception_list)", filled in (most of) the blanks with
essentially random names, and repeated the unsupported assertion that
it's useful.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Jerry Coffin]

In article <11*********************@o61g2000hsh.googlegroups. com>,
ja*********@gmail.com says...

On Jul 24, 8:34 pm, Jerry Coffin <[e-mail]:

In article <[e-mail]>, [e-mail] says...

[...]

They just don't work as in Java.

Irrelevant -- Java's exception specifications are no better.

They're actually worse, because you can't specify the most
interesting case.

I'll take your word for it -- I've used Java exceptions enough to be
quite certain they're no better. I found them more problematic, but
hadn't used them _quite_ enough to be sure the extra problems were
really their fault rather than mine.

[ ... ]

If you're trying to write exception safe code, you need some
sort of guarantee that certain functions (swap, for example,
with some common idioms) or operations don't throw.

True, but I'm not convinced that exception specifications are a good way
to accomplish that.

[ ... ]

If the contractual guarantee is that the function won't throw X,
then aborting the program if it does sounds very much like what
I'd want. It's what assert does for the (many) other checks I
write.

The difference, at least as I see it, is that assert helps you gather
information about the problem, whereas exception specifications throw
away the information that was available.

assert prints out a little bit of useful information before aborting --
but unexpected() just aborts or throws a bad_exception. bad_exception,
in turn, provides no way to retrieve information about the original
exception to help diagnose the problem.

Even if, for example, bad_exception contained a pointer to the original
exception, the whole mechanism would become far more useful in a hurry.
The problem with that, of course, is that we don't know the type for the
pointer -- even though (nearly?) everybody agrees that exception classes
should be a monolithic hierarchy, C++ doesn't require it, so we don't
know what type that pointer should be. If nothing else, it could be a
void *, so you could at least cast it back to the base of the hierarchy
-- but when unexpected() is called, it doesn't receive (a pointer or
reference to) the original exception object, so we can't even do that
much.

Likewise, if unexpected() could find that the exception was (derived
from) std::exception, it could do something like:
std::cerr << original_exception->what();
to give you at least some clue of what went wrong before aborting your
program.

If these were possible and implemented, I'd agree that exception
specifications would become as useful as assert's. Without something
along that line, however, I'm left wondering how they can be considered
even roughly comparable.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[James Kanze]

On Jul 25, 6:47 pm, Jerry Coffin <[e-mail]:

In article <[e-mail]. com>,
[e-mail] says...

On Jul 24, 8:34 pm, Jerry Coffin <[e-mail]:

In article <[e-mail]>, [e-mail] says....

[...]

They just don't work as in Java.

Irrelevant -- Java's exception specifications are no better.

They're actually worse, because you can't specify the most
interesting case.

I'll take your word for it -- I've used Java exceptions enough to be
quite certain they're no better. I found them more problematic, but
hadn't used them _quite_ enough to be sure the extra problems were
really their fault rather than mine.

The problem is simple: the only really interesting guarantee is
that a function won't throw at all, and in Java, it's impossible
to write such a function. (How can you guarantee that a
function won't raise VirtualMachineError.)

The problem is really deeper than exception specifications. For
some types of errors (like VirtualMachineError, or
AssertionError), even trying to unwind the stack is dangerous.
You want to stop dead. With prejudice. The problem is that
Java refuses to recognize this.

[ ... ]

If you're trying to write exception safe code, you need some
sort of guarantee that certain functions (swap, for example,
with some common idioms) or operations don't throw.

True, but I'm not convinced that exception specifications are
a good way to accomplish that.

[ ... ]

If the contractual guarantee is that the function won't throw X,
then aborting the program if it does sounds very much like what
I'd want. It's what assert does for the (many) other checks I
write.

The difference, at least as I see it, is that assert helps you gather
information about the problem, whereas exception specifications throw
away the information that was available.

assert prints out a little bit of useful information before aborting --
but unexpected() just aborts or throws a bad_exception. bad_exception,
in turn, provides no way to retrieve information about the original
exception to help diagnose the problem.

unexpected() aborts, period. By default at least. And if I
write "throw()" after the function declaration, I am guaranteed,
no matter what, that no exception will leave the function, ever,
and that the stack will never be unwound accross the function
boundary.

After that, I've got a core dump, which should give me all the
information I need. Exactly like assert. (Note that when my
application programs run, standard error is normally connected
to /dev/null. So any message assert may output is lost. It's
the core dump which has the useful information, however.)

Even if, for example, bad_exception contained a pointer to the original
exception, the whole mechanism would become far more useful in a hurry.
The problem with that, of course, is that we don't know the type for the
pointer -- even though (nearly?) everybody agrees that exception classes
should be a monolithic hierarchy, C++ doesn't require it, so we don't
know what type that pointer should be.

The fact that you can't copy an exception of an unknown type is
a problem in general; it makes it impossible to propagate an
exception accross a join, for example. I think there will be
some evolution concerning this in the next version of the
standard. I'm not particularly worried about bad_exception,
however, because I'll never see it.

If nothing else, it could be a
void *, so you could at least cast it back to the base of the hierarchy
-- but when unexpected() is called, it doesn't receive (a pointer or
reference to) the original exception object, so we can't even do that
much.

Likewise, if unexpected() could find that the exception was (derived
from) std::exception, it could do something like:
std::cerr << original_exception->what();
to give you at least some clue of what went wrong before aborting your
program.

If these were possible and implemented, I'd agree that exception
specifications would become as useful as assert's. Without something
along that line, however, I'm left wondering how they can be considered
even roughly comparable.

An exception specification without bad_exception will not cause
bad_exception to be raised. Since the only really useful
exception specification is an empty one, which doesn't allow
bad_exception, you should never see this exception. terminate()
will be called, and the core dump will point you to the exact
line where the exception was raised, along with giving you ca
stack trace back to the function which thought it wasn't
possible.

--
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]

[Pete Becker]

On 2007-07-26 10:34:54 -0400, James Kanze <ja*********@gmail.comsaid:

>
The fact that you can't copy an exception of an unknown type is
a problem in general; it makes it impossible to propagate an
exception accross a join, for example. I think there will be
some evolution concerning this in the next version of the
standard.

It was voted in at last week's meeting: N2179, "Language Support for
Transporting Exceptions between Threads". While copying exceptions
across a join was the motivating factor, the mechanism does not depend
on the presence of threads. You can save a handle to an exception and
rethrow it later.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

[Jerry Coffin]

In article <11**********************@r34g2000hsd.googlegroups .com>,
ja*********@gmail.com says...

[ ... ]

unexpected() aborts, period. By default at least.

I suppose that depends on what you mean by default -- if the exception
specification in question includes bad_exception, the stock version
(i.e. not as a result of set_unexpected) can/will throw objects of type
bad_exception. Of course, as long as you only write empty exception
specifications, that can't happen...

And if I
write "throw()" after the function declaration, I am guaranteed,
no matter what, that no exception will leave the function, ever,
and that the stack will never be unwound accross the function
boundary.

Quite true.

After that, I've got a core dump, which should give me all the
information I need.

At least you hope so.

Exactly like assert. (Note that when my
application programs run, standard error is normally connected
to /dev/null. So any message assert may output is lost. It's
the core dump which has the useful information, however.)

I, for one, find the information supplied by the assert useful. Yes,
there are times it can be/is discarded, but at least to me there's a big
difference between deciding that it's reasonable to discard information
for your specific application(s), and deciding at the language level
that all such information must be discarded for all possible
applications.

[ ... ]

An exception specification without bad_exception will not cause
bad_exception to be raised. Since the only really useful
exception specification is an empty one, which doesn't allow
bad_exception, you should never see this exception.

I can't agree -- if you're seeing an exception raised that shouldn't be,
I think (a modified version of) bad_exception would be a useful way to
help diagnose the problem.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[James Kanze]

On Jul 27, 4:06 am, Jerry Coffin <[e-mail]:

In article <[e-mail] .com>,
[e-mail] says...
[ ... ]

unexpected() aborts, period. By default at least.

I suppose that depends on what you mean by default -- if the exception
specification in question includes bad_exception, the stock version
(i.e. not as a result of set_unexpected) can/will throw objects of type
bad_exception. Of course, as long as you only write empty exception
specifications, that can't happen...

Are you sure? I'm looking at the lastest draft of the standard
(but I don't think anything has changed here), and for
unexpected_handler, it says: "Default behavior: The
implementation's default unexpected_handler calls terminate()."
It's only if a user defined unexpected_handler throws an
exception that bad_exception comes into play.

And if I
write "throw()" after the function declaration, I am guaranteed,
no matter what, that no exception will leave the function, ever,
and that the stack will never be unwound accross the function
boundary.

Quite true.

After that, I've got a core dump, which should give me all the
information I need.

At least you hope so.

Exactly like assert. (Note that when my
application programs run, standard error is normally connected
to /dev/null. So any message assert may output is lost. It's
the core dump which has the useful information, however.)

I, for one, find the information supplied by the assert useful.

It can be useful. It's very useful in my unit tests, for
example. If you're implementation of std::vector<>::operator[]
asserts, however, I'm not sure that the message will be very
useful. My experience is that in large applications, the assert
is usually in a function which has been called with the wrong
arguments, and you still have to determine who called it.

Yes,
there are times it can be/is discarded, but at least to me there's a big
difference between deciding that it's reasonable to discard information
for your specific application(s), and deciding at the language level
that all such information must be discarded for all possible
applications.

At least on my systems, calling unexpected doesn't discard any
information. It just doesn't output anything on standard error.
The stack has not been unwound, and the critial information is
there in the core dump (at least most of it, most of the time).

Probably, an assert instead of the throw would be even more
useful. But if the code is wrong, the core dump from unexpected
is better than nothing.

[ ... ]

An exception specification without bad_exception will not cause
bad_exception to be raised. Since the only really useful
exception specification is an empty one, which doesn't allow
bad_exception, you should never see this exception.

I can't agree -- if you're seeing an exception raised that shouldn't be,
I think (a modified version of) bad_exception would be a useful way to
help diagnose the problem.

How? If you catch it, the stack has been unwound, so you don't
know where you were. And you've probably violated some pretty
important invariants. If you don't catch it, then you get a
core dump. In which the stack may have been unwound (although
as a QoI issue, I would expect it not to have been).

That's with the current situation, of course. If it were
somehow possible to obtain information about the original
exception, it might be more useful. But I still prefer a core
dump.

--
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]

[Jerry Coffin]

In article <11**********************@r34g2000hsd.googlegroups .com>,
ja*********@gmail.com says...

On Jul 27, 4:06 am, Jerry Coffin <[e-mail]:

[ ... ]

I suppose that depends on what you mean by default -- if the exception
specification in question includes bad_exception, the stock version
(i.e. not as a result of set_unexpected) can/will throw objects of type
bad_exception. Of course, as long as you only write empty exception
specifications, that can't happen...

Are you sure? I'm looking at the lastest draft of the standard
(but I don't think anything has changed here), and for
unexpected_handler, it says: "Default behavior: The
implementation's default unexpected_handler calls terminate()."
It's only if a user defined unexpected_handler throws an
exception that bad_exception comes into play.

$15.5.2/2 [except.unexpected]:

If it throws or rethrows an exception that the exception-
specification does not allow then the following happens:
If the exception-pecification does not include the class
std::bad_exception (18.6.2.1) then the function
terminate() is called, otherwise the thrown exception is
replaced by an implementation-defined object of the type
std::bad_exception and the search for another handler
will continue at the call of the function whose
exception-specification was violated.

As of N2315, dated 2007-06-25, this remains unchanged.

[ ... ]

At least on my systems, calling unexpected doesn't discard any
information. It just doesn't output anything on standard error.
The stack has not been unwound, and the critial information is
there in the core dump (at least most of it, most of the time).

My point is that by the time unexpected() is called, the original
exception object has disappeared; that's what I'm talking about as
useful information having been discarded -- at least assuming you design
your exception classes well, it's like to contain much more specific
information about the exact problem than a core dump.

Based on Howard's post, however, it appears that in the next version of
the standard, that exception object will beceome available. As such,
this entire problem is (largely) cured, at least as well as writing the
standard can make it so -- now it's just up to the vendors to implement
the new behavior.

Probably, an assert instead of the throw would be even more
useful. But if the code is wrong, the core dump from unexpected
is better than nothing.

Yes, it's better than nothing -- but I think access to the original
exception object is frequently going to be a lot better still.

[ ... ]

That's with the current situation, of course. If it were
somehow possible to obtain information about the original
exception, it might be more useful. But I still prefer a core
dump.

Information about the original exception doesn't rule out a core dump
though -- rather the contrary, if the program aborts, I'd expect a core
dump as well. Sometimes the core dump might be more useful -- but at
least at that point I have the option of looking at the original
exception object, and chances are pretty good that I can quickly
determine whether it's useful, and proceed to using the core dump if
(and only if) it's not.

--
Later,
Jerry.

The universe is a figment of its own imagination.