Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #8399 > unrolled thread

Bug, feature or just accidental?

Back to article view | Back to comp.lang.c++

Contents

  Bug, feature or just accidental? boltar2003@boltar.world - 2011-08-02 08:49 +0000
    Re: Bug, feature or just accidental? Ian Collins <ian-news@hotmail.com> - 2011-08-02 20:55 +1200
      Re: Bug, feature or just accidental? boltar2003@boltar.world - 2011-08-02 10:21 +0000
        Re: Bug, feature or just accidental? Miles Bader <miles@gnu.org> - 2011-08-02 19:29 +0900
          Re: Bug, feature or just accidental? boltar2003@boltar.world - 2011-08-02 10:35 +0000
            Re: Bug, feature or just accidental? Ian Collins <ian-news@hotmail.com> - 2011-08-02 22:42 +1200
              Re: Bug, feature or just accidental? boltar2003@boltar.world - 2011-08-02 11:16 +0000
                Re: Bug, feature or just accidental? Victor Bazarov <v.bazarov@comcast.invalid> - 2011-08-02 08:08 -0400
                  Re: Bug, feature or just accidental? boltar2003@boltar.world - 2011-08-02 12:40 +0000
                    Re: Bug, feature or just accidental? Victor Bazarov <v.bazarov@comcast.invalid> - 2011-08-02 08:59 -0400
                      Re: Bug, feature or just accidental? boltar2003@boltar.world - 2011-08-02 13:23 +0000
                        Re: Bug, feature or just accidental? Victor Bazarov <v.bazarov@comcast.invalid> - 2011-08-02 09:43 -0400
                          Re: Bug, feature or just accidental? boltar2003@boltar.world - 2011-08-02 13:53 +0000
                            Re: Bug, feature or just accidental? James Lothian <james@firstnamelastname.freeserve.co.uk> - 2011-08-03 07:49 +0100
                            Re: Bug, feature or just accidental? "Paul" <pchristor@yahoo.co.uk> - 2011-08-03 10:47 +0100
                    Re: Bug, feature or just accidental? Paavo Helde <myfirstname@osa.pri.ee> - 2011-08-02 15:43 -0500
                Re: Bug, feature or just accidental? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-08-02 16:12 +0000
        Re: Bug, feature or just accidental? Ian Collins <ian-news@hotmail.com> - 2011-08-02 22:32 +1200

#8399 — Bug, feature or just accidental?

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

[toc] | [next] | [standalone]

#8400

On 08/ 2/11 08:49 PM, boltar2003@boltar.world wrote:
> 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.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#8402

On Tue, 02 Aug 2011 20:55:18 +1200
Ian Collins <ian-news@hotmail.com> wrote:
>> 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.

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

[toc] | [prev] | [next] | [standalone]

#8403

boltar2003@boltar.world writes:
>>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.

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

-- 
Laughter, n. An interior convulsion, producing a distortion of the features
and accompanied by inarticulate noises. It is infectious and, though
intermittent, incurable.

[toc] | [prev] | [next] | [standalone]

#8405

On Tue, 02 Aug 2011 19:29:08 +0900
Miles Bader <miles@gnu.org> wrote:
>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

[toc] | [prev] | [next] | [standalone]

#8406

On 08/ 2/11 10:35 PM, boltar2003@boltar.world wrote:
> On Tue, 02 Aug 2011 19:29:08 +0900
> Miles Bader<miles@gnu.org>  wrote:
>> 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.

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

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#8408

On Tue, 02 Aug 2011 22:42:18 +1200
Ian Collins <ian-news@hotmail.com> wrote:
>On 08/ 2/11 10:35 PM, boltar2003@boltar.world wrote:
>> On Tue, 02 Aug 2011 19:29:08 +0900
>> Miles Bader<miles@gnu.org>  wrote:
>>> 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.
>
>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

[toc] | [prev] | [next] | [standalone]

#8409

On 8/2/2011 7:16 AM, boltar2003@boltar.world wrote:
> On Tue, 02 Aug 2011 22:42:18 +1200
> Ian Collins<ian-news@hotmail.com>  wrote:
>> On 08/ 2/11 10:35 PM, boltar2003@boltar.world wrote:
>>> On Tue, 02 Aug 2011 19:29:08 +0900
>>> Miles Bader<miles@gnu.org>   wrote:
>>>> 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.
>>
>> 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.

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
-- 
I do not respond to top-posted replies, please don't ask

[toc] | [prev] | [next] | [standalone]

#8410

On Tue, 02 Aug 2011 08:08:58 -0400
Victor Bazarov <v.bazarov@comcast.invalid> wrote:
>> 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 

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

[toc] | [prev] | [next] | [standalone]

#8411

On 8/2/2011 8:40 AM, boltar2003@boltar.world wrote:
> On Tue, 02 Aug 2011 08:08:58 -0400
> Victor Bazarov<v.bazarov@comcast.invalid>  wrote:
>>> 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
>
> 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.

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
-- 
I do not respond to top-posted replies, please don't ask

[toc] | [prev] | [next] | [standalone]

#8412

On Tue, 02 Aug 2011 08:59:52 -0400
Victor Bazarov <v.bazarov@comcast.invalid> wrote:
>> 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.

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

[toc] | [prev] | [next] | [standalone]

#8413

On 8/2/2011 9:23 AM, boltar2003@boltar.world wrote:
> On Tue, 02 Aug 2011 08:59:52 -0400
> Victor Bazarov<v.bazarov@comcast.invalid>  wrote:
>>> 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.
>
> 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.

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

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
-- 
I do not respond to top-posted replies, please don't ask

[toc] | [prev] | [next] | [standalone]

#8414

On Tue, 02 Aug 2011 09:43:29 -0400
Victor Bazarov <v.bazarov@comcast.invalid> wrote:
>> Congratulations on completely missing my point.
>
>Which was what, exactly?

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

> > Using that logic perhaps
>> function calls should only allow one function call parameter then?
>
>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? 

Fuck off back under your bridge you pathetic troll.

B2003

[toc] | [prev] | [next] | [standalone]

#8427

boltar2003@boltar.world wrote:

>
> Fuck off back under your bridge you pathetic troll.
>
> B2003
>
>

*PLONK*


-- 
---------------------------------------------
demangle my email address in the obvious way.

[toc] | [prev] | [next] | [standalone]

#8429

<boltar2003@boltar.world> wrote in message 
news:j18vg8$5ir$1@speranza.aioe.org...
> On Tue, 02 Aug 2011 09:43:29 -0400
> Victor Bazarov <v.bazarov@comcast.invalid> wrote:
>>> Congratulations on completely missing my point.
>>
>>Which was what, exactly?
>
> Try re-reading what I wrote. Who knows, maybe enlightenment will come.
>
>> > Using that logic perhaps
>>> function calls should only allow one function call parameter then?
>>
>>Perhaps.  Is there logic in that?
>
> About as much logic as only allowing one argument in a throw.
>
If, during program execution, an error occurs it throws the error at that 
point. It cannot throw 2 errors and its not right to look at the exception 
object as a function argument. I haven't examined the techincalities of EH 
thoroughly but I think the sequence of execution for a try/catch block will 
not be same as a function call.
For example with:
try{...blah1...}
catch(bleeurgh1){..blah..}
catch(...){...blah..}

Is blah1 executed in a some special process in case it burns and crashes?

Why can't we have catch(e1, e2) ?






>> > 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?
>
> Fuck off back under your bridge you pathetic troll.
>
> B2003
>
> 


--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#8423

boltar2003@boltar.world wrote in news:j18r7r$qjd$1@speranza.aioe.org:

> On Tue, 02 Aug 2011 08:08:58 -0400
> Victor Bazarov <v.bazarov@comcast.invalid> wrote:
>>> 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 
> 
> 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. 

If you want to throw such pieces together as e.g. int, string, string, 
then there is a lot of informal assumptions about what they mean; another 
piece of code might throw the same things with totally different meaning. 
The user of your library will write the catch statement but he would not 
have a clear idea what to catch and how to handle these exceptions. 

By their nature the throw and catch sites are quite separated in the 
code; if they were very close, one should not use the exceptions. So in 
order to make the separated pieces of code to work together, one must 
provide a piece of context how to interpret the exception. In C++ this is 
done by typing rules, one can catch different types and decide by the 
type what needs to be done.

So lets assume you will wrap the column name in an specific exception 
type ColumnNameException. The caller can now catch it and recover the 
column name. So what? The caller does not know in which table the column 
is and what error did it produce. In order to be useful, the caller would 
have to catch all the pieces together:

catch(DatabaseErrorCodeException a, DatabaseTableNameException b, 
DatabaseColumnName c) {...}

If anything is changed in that schema, all the catch sites must be 
updated, which is tedious and error-prone. One cannot rely on compiler to 
detect errors (a la the DatabaseException class does not have Column() 
method) as any random not yet written piece of software could throw the 
same exception types. In order to get any robustness one has to pack the 
data together and give the collection a distinct name like 
DatabaseException so that the compiler could do some checking of the 
usage of this type. And voila, we arrive back to the C++ way of doing 
things! Welcome to the world of custom types, OOP and strong typing!

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

And lose some important design goals of C++ like strong typing and static 
code verification on the way.

Cheers
Paavo

[toc] | [prev] | [next] | [standalone]

#8420

On Tue, 2011-08-02, boltar2003@boltar.world wrote:
> On Tue, 02 Aug 2011 22:42:18 +1200
> Ian Collins <ian-news@hotmail.com> wrote:
>>On 08/ 2/11 10:35 PM, boltar2003@boltar.world wrote:
>>> On Tue, 02 Aug 2011 19:29:08 +0900
>>> Miles Bader<miles@gnu.org>  wrote:
>>>> 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.
>>
>>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. 

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::pair<MyException, int>
  std::pair<MyException, Foo>
  std::pair<MySpecificException, Bar>

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

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#8404

On 08/ 2/11 10:21 PM, boltar2003@boltar.world wrote:
> On Tue, 02 Aug 2011 20:55:18 +1200
> Ian Collins<ian-news@hotmail.com>  wrote:
>>> 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.
>
> 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.

-- 
Ian Collins

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web