throwable .vs. non throwable? - c++

* 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 F> std::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.

That's an exception specification. It specifies which types of
exceptions a function can throw. It doesn't cause exceptions to be thrown.


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

You mean, apparently it does distinguish. You forgot to place the same
throw specification on the second overload.


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

Uhm, what's wrong with boost::lexical_cast?

But anyway, what you're describing is parameterizing the function with
whether it should throw or not. For that you can check the fail()
member function. If failure and should throw, then throw.

You can pass that parameter as a template parameter (decision at compile
time) or as an ordinary function argument (decision at run time). It
might seem natural to use bool for this. But I advice definining a
suitable enum type, so that the client code becomes more readable --
and that also goes for silly shorthand "Strm": vowels are cheap and
plentiful, there's no need to avoid using them! ;-)

Hope this helps,

- Alf


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

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 F> std::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

On Jul 24, 3:39 am, "Jim Langston" <tazmas...@rocketmail.com> 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 F> std::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:james.kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

In article <46a5b550.1661669@news.utanet.at>, rpbg123@yahoo.com says...

[ ... ]

> You misunderstood exception specifications in C++. In general,
> templates and exception specifications don't blend.

Exception specifictions don't blend with coding in general, even without
templates. My advice, at least, is to not use exception specifications
at all, ever.

A few people point out that (at least in theory) an empty exception
specification can allow better optimization of some code under some
circumstances. IMO, this isn't sufficient to justify their use, but
there are some who consider this sufficient justification for using
empty exception specifications.

I don't know of anybody who recommends any other use of exception
specifications at all.

--
Later,
Jerry.

The universe is a figment of its own imagination.

On Tue, 24 Jul 2007 08:18:41 -0600, Jerry Coffin wrote:
>Exception specifictions don't blend with coding in general, even without
>templates. My advice, at least, is to not use exception specifications
>at all, ever.

Some people propagated this point of view in the past (the
Stroustrup-had-a-bad-day theory). Actually, exception specifications
are not more broken than any other feature of the C++ language. They
just don't work as in Java. It's neither necessary nor advisable to
define exception specifications for each function. But being able to
specify exception guarantees in code (and not merely in the
documentation) definitely is an advantage.


--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch

In article <46a63bfc.10204323@news.utanet.at>, rpbg123@yahoo.com says...
> On Tue, 24 Jul 2007 08:18:41 -0600, Jerry Coffin wrote:
> >Exception specifictions don't blend with coding in general, even without
> >templates. My advice, at least, is to not use exception specifications
> >at all, ever.
>
> Some people propagated this point of view in the past (the
> Stroustrup-had-a-bad-day theory).

I haven't (and don't) particularly blame Bjarne for them -- I'm not at
all sure he single-handedly added them, or anything like it.

> Actually, exception specifications
> are not more broken than any other feature of the C++ language.

If you take "broken" to mean "doesn't/can't work as specified", then I'd
agree -- quite a few compilers implement them as the standard requires.

If you take "broken" to mean "they aren't useful", then I have to
disagree -- I believe that every program that includes even a single
exception specification can be written better without it. In most
(though perhaps not quite all) cases, the only change necessary for this
improvement is to delete the text of the exception specification itself.

> They just don't work as in Java.

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

> It's neither necessary nor advisable to define exception specifications
> for each function.

....or _any_ function.

> But being able to
> specify exception guarantees in code (and not merely in the
> documentation) definitely is an advantage.

How? When? Please show us a real example. 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. Quite the contrary, they
normally abort the program without any chance at any kind of recovery,
which is pretty much exactly the opposite of what you'd typically want.

Simply making a bald assertion that they're useful doesn't cut it in
this case. Given the results of years of experience with them, any claim
that they're useful needs to be accompanied by a concrete example.

--
Later,
Jerry.

The universe is a figment of its own imagination.

"James Kanze" <james.kanze> wrote in message
news:1185281925.224357.196390@m3g2000hsh.googlegroups.com...
On Jul 24, 3:39 am, "Jim Langston" <tazmas...@rocketmail.com> wrote:
[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.

On Tue, 24 Jul 2007 12:34:26 -0600, Jerry Coffin wrote:
>rpbg123@...com says...
>> But being able to
>> specify exception guarantees in code (and not merely in the
>> documentation) definitely is an advantage.
>
>How? When? Please show us a real example.

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

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

>Quite the contrary, they
>normally abort the program without any chance at any kind of recovery,
>which is pretty much exactly the opposite of what you'd typically want.

If your program crashes because you declared the wrong exception
specification then it's your fault. BTW, C++ exception specifications
don't work as in Java.

>Simply making a bald assertion that they're useful doesn't cut it in
>this case. Given the results of years of experience with them, any claim
>that they're useful needs to be accompanied by a concrete example.

All decent C++ libraries need them (except maybe templatized low level
stuff).


--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch

On Jul 24, 8:34 pm, Jerry Coffin <jcof...@taeus.com> wrote:
> In article <46a63bfc.10204...@news.utanet.at>, rpbg...@yahoo.com 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.

> > It's neither necessary nor advisable to define exception
> > specifications for each function.

> ...or _any_ function.

> > But being able to
> > specify exception guarantees in code (and not merely in the
> > documentation) definitely is an advantage.

> How? When? Please show us a real example.

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. As long as
it's just assigning a pointer, fine. You have the nothrow
guarantee from the language. If it involves calling a function,
however, you need a guarantee from the author of the function.
Using an empty exception specification is a simple way of
documenting this guarantee, and it acts very much like an
assert, which fails if the guarantee is broken.

> 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. Quite the contrary, they
> normally abort the program without any chance at any kind of
> recovery, which is pretty much exactly the opposite of what
> you'd typically want.

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.

Most of the time, the only guarantee which interests you with
regards to what won't be thrown is the nothrow guarantee.
(There might be exceptions, but I've never encountered them.)
In theory, at least, it would be nice to have some sort of
guarantee as to what will be thrown: if condition X holds,
exception Y will be thrown. I rather think that this is beyond
the current state of compiler capabilities, so we're left with
documentation and code review.

> Simply making a bald assertion that they're useful doesn't cut
> it in this case. Given the results of years of experience with
> them, any claim that they're useful needs to be accompanied by
> a concrete example.

Are assert's useful? I find them to be very useful. The C++
exception specification is a sort of an assert with regards to
what might be thrown. The nothrow contract is very important in
some specific cases, and exception specifications are a means of
asserting it.

--
James Kanze (GABI Software) email:james.kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34