Valentin Bonnard wrote:
>> The standard explicitly says that it is allowed:
>>
>> 15.3/5: The handlers for a try block are tried in order of
>> appearance. That makes it possible to write handlers that can
>> never be executed, for example by placing a handler for a
>> derived class after a handler for a corresponding base class.

Biju Thomas wrote:
> What is the rationale for such a feature? It seems totally pointless
> to me. A compile-time error would have been more useful.

It's conceivable that a catch handler that is a derived class of a
previous catch handler, and thus is never executed, could in the
future no longer be a derived class of the previous catch if the
types were changed so that the second catch type is no longer a
derived type of the first.

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Biju Thomas wrote:

>
>
> What is the rationale for such a feature? It seems totally pointless to
> me. A compile-time error would have been more useful.
>

See scotts' original post. He gives an example when it is usefull (maybe =
not
essential :)).

--

Claude Qu=E9zel (claude_quezel@syntell.corba)
anti-spam: replace corba by com in private replies


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

scott at 3dfx dot com wrote:

> I'm pretty sure this isn't legal, but couldn't find the relevant part of the
> standard.
>
> try {
>     // ...
> }
>
> catch ( InternalEx1 ) { throw; }
> catch ( InternalEx2 ) { throw; }
> catch ( AppEx ) { }
>
> catch ( InternalEx1 ) { throw; } // InternalEx1 already handled above..
> error?
> catch ( InternalEx2 ) { throw; }
> catch ( ... ) { }

The standard explicitly says that it is allowed:

15.3/5: The handlers for a try block are tried in order of
appearance. That makes it possible to write handlers that can
never be executed, for example by placing a handler for a
derived class after a handler for a corresponding base class.

--

Valentin Bonnard

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I'm pretty sure this isn't legal, but couldn't find the relevant part of the
standard.

try {
    // ...
}

catch ( InternalEx1 ) { throw; }
catch ( InternalEx2 ) { throw; }
catch ( AppEx ) { }

catch ( InternalEx1 ) { throw; } // InternalEx1 already handled above..
error?
catch ( InternalEx2 ) { throw; }
catch ( ... ) { }


This code is being created as a result of a macro that looks like this:

#define catch(E) \
         catch(InternalEx1) \
         { \
            throw; \
         } \
         catch(InternalEx2) \
         { \
            throw; \
         } \
         catch(E)


Then the app will do something like this:

try {
    // ...
}

catch ( AppEx ) { }
catch ( ... ) { }


The point, of course, is to prevent InternalEx1 and InternalEx2 from being
masked if the application uses catch ( ... ) (this is in a pthreads library
for win32, BTW).  VC++ won't compile it, but apparently gcc will.  Can
anyone confirm or deny the legality of this?







---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Valentin Bonnard wrote:
>
> scott at 3dfx dot com wrote:
>
> > I'm pretty sure this isn't legal, but couldn't find the relevant part of the
> > standard.
> >
> > try {
> >     // ...
> > }
> >
> > catch ( InternalEx1 ) { throw; }
> > catch ( InternalEx2 ) { throw; }
> > catch ( AppEx ) { }
> >
> > catch ( InternalEx1 ) { throw; } // InternalEx1 already handled above..
> > error?
> > catch ( InternalEx2 ) { throw; }
> > catch ( ... ) { }
>
> The standard explicitly says that it is allowed:
>
> 15.3/5: The handlers for a try block are tried in order of
> appearance. That makes it possible to write handlers that can
> never be executed, for example by placing a handler for a
> derived class after a handler for a corresponding base class.

What is the rationale for such a feature? It seems totally pointless to
me. A compile-time error would have been more useful.

--
Biju Thomas

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]