Bug, feature or just accidental?

[boltar2003]

Hello

I have a question - why can I throw but not catch multiple objects at the
same time?

eg:

#include <stdio.h>

int main()
{
try
{
throw(1,2);
}
catch(int i)
{
printf("caught %d\n",i);
}
return 0;
}

If I have catch(int i, int j) I get a compile error with gcc but the throw
compiles fine. Also if I have brackets around the throw values it catches
the 2, if I miss out the brackets it catches the 1. Is it simply treating
the brackets as a single expression?

B2003

 

[Ian Collins]

Hello

I have a question - why can I throw but not catch multiple objects at the
same time?

eg:

#include<stdio.h>

int main()
{
try
{
throw(1,2);
}
catch(int i)
{
printf("caught %d\n",i);
}
return 0;
}

If I have catch(int i, int j) I get a compile error with gcc but the throw
compiles fine. Also if I have brackets around the throw values it catches
the 2, if I miss out the brackets it catches the 1. Is it simply treating
the brackets as a single expression?

You are seeing the comma operator in action.

throw(1,2) is throw (1,2). The result of the expression 1,2 is 2.

throw 1,2 is (throw 1),2. Here the result (2) is discarded.

 

[boltar2003]

You are seeing the comma operator in action.

throw(1,2) is throw (1,2). The result of the expression 1,2 is 2.

throw 1,2 is (throw 1),2. Here the result (2) is discarded.

Fair enough, but I'm surprised it doesn't treat comma seperated values
as arguments in the same way as a function call would.

B2003

 

[Miles Bader]

Fair enough, but I'm surprised it doesn't treat comma seperated values
as arguments in the same way as a function call would.

The thing is that the parens are _not_ part of the "throw" statement
(the syntax of throw is just "throw SOMETHING" -- note, no parens),
they're just random parens that you can put around any expression.

This is in contrast with a function-call, where the parens are an
intrinsic part of the function-call syntax; the outermost pair of
parens in a function call are "special", which allows a special
interpretation of commas (directly) inside them.

It's like writing "int a = 1 + (2,3);" which is really just the same
as "int a = 1 + 3;".

-Miles

 

[Ian Collins]

Fair enough, but I'm surprised it doesn't treat comma seperated values
as arguments in the same way as a function call would.

throw isn't a function call.

Throw is defined in the standard as

throw-expression:
throw assignment-expression

The parenthesis are associated with the expression, not the throw.

 

[boltar2003]

The thing is that the parens are _not_ part of the "throw" statement
(the syntax of throw is just "throw SOMETHING" -- note, no parens),
they're just random parens that you can put around any expression.

I think Stroustrup missed a trick there. It would be very useful to throw
multiple values at the same time instead of having to create an object
to hold them in and throw that. Functions arn't limited to a single argument
so I don't really see a good reason why throw-catch is.

B2003

 

[Ian Collins]

I think Stroustrup missed a trick there. It would be very useful to throw
multiple values at the same time instead of having to create an object
to hold them in and throw that. Functions arn't limited to a single argument
so I don't really see a good reason why throw-catch is.

Think of throw as more like a return statement than a function call and
you'll see that argument dose not make sense.

 

[boltar2003]

Think of throw as more like a return statement than a function call and
you'll see that argument dose not make sense.

Why not? Plenty of languages allow multiple return values from a function.
C++ doesn't because its based on C, but thats no reason why a C++ specific
feature such as exceptions couldn't support it.

B2003

 

[Victor Bazarov]

Why not? Plenty of languages allow multiple return values from a function.
C++ doesn't because its based on C, but thats no reason why a C++ specific
feature such as exceptions couldn't support it.

Right, but letting throw accept multiple objects would present an
inconsistency with the 'return', whereas now it's consistent and
logical. Besides, what's the point of throwing multiple objects? Can
there occur several exceptional situations at once? Seems that the most
severe is always what you want to report [by throwing]. And, just like
with returning from a function, you're free to wrap your multiple
objects in a struct and throw that.

V

 

[boltar2003]

Right, but letting throw accept multiple objects would present an
inconsistency with the 'return', whereas now it's consistent and

Why does it have to be consistent with return? A function return and an
exception handler are 2 logically different things. If consistency is the
name of the game why do try and catch both require curly brackets around
a block even if there's only a single expression in the block? Looping
constructs don't, "if" doesn't.

logical. Besides, what's the point of throwing multiple objects? Can
there occur several exceptional situations at once? Seems that the most

Perhaps you have a database error and wish to through the error number along
with the table and column names. There are a million other examples.

severe is always what you want to report [by throwing]. And, just like
with returning from a function, you're free to wrap your multiple
objects in a struct and throw that.

Sure, but why should you have to? Its an inefficient extra step that could be
eliminated if the language had been designed differently.

B2003

 

[Victor Bazarov]

Why does it have to be consistent with return? A function return and an
exception handler are 2 logically different things. If consistency is the
name of the game why do try and catch both require curly brackets around
a block even if there's only a single expression in the block? Looping
constructs don't, "if" doesn't.


Perhaps you have a database error and wish to through the error number along
with the table and column names. There are a million other examples.

What you throw is an exception *object*. You shouldn't need to *throw*
an error number or the table and column *names*. Those should be the
data you stuff in your database exception object.

severe is always what you want to report [by throwing]. And, just like
with returning from a function, you're free to wrap your multiple
objects in a struct and throw that.

Sure, but why should you have to? Its an inefficient extra step that could be
eliminated if the language had been designed differently.

You have to because such is the design of the language. If you don't
want to have to, use the language where it's designed the way you want
it to be designed. Or design your own. I am sure whatever you can come
up with will have no shortcomings whatsoever.

V

 

[boltar2003]

What you throw is an exception *object*. You shouldn't need to *throw*
an error number or the table and column *names*. Those should be the
data you stuff in your database exception object.

Congratulations on completely missing my point. Using that logic perhaps
function calls should only allow one function call parameter then? Want to
pass 2 or more? Just stuff them into a parameter object. Whats the problem?

You have to because such is the design of the language. If you don't

No shit. Any more stunning revelations from you coming soon? I was simply
commenting on how it was a missing opportunity.

B2003

 

[Victor Bazarov]

Congratulations on completely missing my point.

Which was what, exactly?

Using that logic perhaps
function calls should only allow one function call parameter then?

Perhaps. Is there logic in that?

Want to
pass 2 or more? Just stuff them into a parameter object. Whats the problem?

There is no problem. There is however, backward compatibility [with C].
Design your own language from scratch, and you will have no such
constraints.

No shit. Any more stunning revelations from you coming soon?

Any more bogus complaints from you? How about the absence of power
operator for built-in arithmetic types?

I was simply
commenting on how it was a missing opportunity.

Don't. It makes no sense for a standardized programming language. If
you need a new feature added to the language, go to 'comp.std.c++' and
propose it. *If* it has merit, it's going to be included in the next
revision.

We're all bound by limitations in our lives. Some limitations are
inherent, some are artificial. All of them serve some kind of purpose.
Here, for instance, it *might have been* the simplicity of
implementing that feature. But it doesn't matter. The language is what
it is now. What is the damn point of "commenting on how it was a
missing opportunity"? There are probably hundreds of features that
haven't made it into the language. Are you going to seek them all out
one by one and "comment" on them? I see it as a waste of time, to be
honest. Unless, of course, you're using that "missing opportunity" to
improve the existing language (when are we going to see a proposal from
you in 'comp.std.c++'?) or to come up with your own (the name 'D' is
already taken, so, what's yours going to be called?)

V

 

[boltar2003]

Which was what, exactly?

Try re-reading what I wrote. Who knows, maybe enlightenment will come.

Perhaps. Is there logic in that?

About as much logic as only allowing one argument in a throw.

Want to
pass 2 or more? Just stuff them into a parameter object. Whats the problem?

There is no problem. There is however, backward compatibility [with C].

As I already stated. Not good at spotting sarcasm are you?

Any more bogus complaints from you? How about the absence of power
operator for built-in arithmetic types?

Personally I find the lack of a logical xor operator more annoying.

We're all bound by limitations in our lives. Some limitations are
inherent, some are artificial. All of them serve some kind of purpose.

Oh puleease! Spare me your piss poor homily.

it is now. What is the damn point of "commenting on how it was a
missing opportunity"? There are probably hundreds of features that

Thats what usenet is about. No one was forcing you to respond. Are you the
self appointed moderator of this group or something?

**** off back under your bridge you pathetic troll.

B2003

 

[Jorgen Grahn]

Why not? Plenty of languages allow multiple return values from a function.

I get the feeling you come from languages like Python or Haskell with
a more easy-going type system. In C++, such a tuple would need a type,
and the type would have to exist at both the throw site and the catch
site. So you would have name its type, and see it as one object rather
than multiple values:

return std::make_pair(42, "foo");

I'm unsure how that would work out with 'throw' since you generally want
your exceptions fit into an inheritance hierarchy. There is no
inheritance relationship between types like

std:air<MyException, int>
std:air<MyException, Foo>
std:air<MySpecificException, Bar>

Instead, do it the C++ way. Find out what information you want your
exceptions to contain, and write those classes.

/Jorgen

 

[James Lothian]

**** off back under your bridge you pathetic troll.

B2003

*PLONK*