Shezan Baig wrote:
> John Nagle wrote:
>
>>This is perhaps the only place in C++ where order of statements affects
>>type matching.  Should it work that way?  Should unreachable catch
>>clauses like that be an error?  They're clearly detectable at
>>compile time.
>
>
>
> How about "catch block overload resolution" that behaves the same way
> as function overload resolution?

   struct A {};
   struct B {};
   void f() throws (A, B);

   try { f(); }
   catch (A &) { ... }
   catch (B &) { ... }

would work fine, but as soon as someone adds

   struct C: public A, public B {};

and modifies the implementation of f to throw an instance of C, what
should happen?

-Stephan

> -shez-

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:
> Nikos Chantziaras wrote:
>
> > David Abrahams wrote:
> >
> >> realnc@hotmail.com ("Nikos Chantziaras") writes:
> >>
> >>> ravinderthakur wrote:
> >>>
> >>>> exception handling is generally advertised as one of the major
> >>>> features of the languages such as c++. however due to the lack of
> >>>> standardization in the c++ about the way the exceptions are being
> >>>> handled/propagated, every compiler implements the exceptions
> >>>> handling in a different way.
>
>      I'm not sure what the original poster was really asking for.
> But it might be worthwhile to have stronger language suggesting
> that all exceptions be derived from class "std::exception".
>
>      Misery is catching an exception at "catch ...".  All identifying
> information has been lost at that point.

Not true; you can rethrow and catch to recover the exception type.

>      But there's a problem with deriving exceptions from
> "std::exception".

There are lots of problems with mandating that all exceptions be
derived from std::exception, among them the fact that tons of code
would break.

Bob

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Bob Bell wrote:

> John Nagle wrote:
>>      I'm not sure what the original poster was really asking for.
>> But it might be worthwhile to have stronger language suggesting
>> that all exceptions be derived from class "std::exception".
>>
>>      Misery is catching an exception at "catch ...".  All identifying
>> information has been lost at that point.
>
> Not true; you can rethrow and catch to recover the exception type.

If it's polymorphic, or otherwise selfdescriptive. I don't believe there is
any way to extract type information from fundamental types at runtime.

>>      But there's a problem with deriving exceptions from
>> "std::exception".
>
> There are lots of problems with mandating that all exceptions be
> derived from std::exception, among them the fact that tons of code
> would break.
>
> Bob

Mandating that they _must_ is not the same as strongly suggesting
they /should/ derive from std::exception.  Exception handling should be an
aid to the programmer, not an additional challenge.

My opinion is that the default behavior of the exception handling mechanism
in C++ should produce a message describing as completely as possible any
exception which unwound the stack to to point of popping main().  It would
also be a good idea, if technically feasible, to require all exceptions to
derive from std::exception by default, and provide a mechanism to override
that restriction in order to support legacy, and esoteric code.
--

Stephan Bergmann wrote:
> Shezan Baig wrote:
>
>> John Nagle wrote:
>>
>>> This is perhaps the only place in C++ where order of statements affects
>>> type matching.  Should it work that way?  Should unreachable catch
>>> clauses like that be an error?  They're clearly detectable at
>>> compile time.
>>
>>
>>
>>
>> How about "catch block overload resolution" that behaves the same way
>> as function overload resolution?
>
>
>   struct A {};
>   struct B {};
>   void f() throws (A, B);
>
>   try { f(); }
>   catch (A &) { ... }
>   catch (B &) { ... }
>
> would work fine, but as soon as someone adds
>
>   struct C: public A, public B {};
>
> and modifies the implementation of f to throw an instance of C, what
> should happen?

     Yes, we hit that because exception specifications aren't taken
seriously.

     Something similar to that happens when you write

 struct A ();
 struct B ();
 struct C: public a, public B();

 void f(A&);
 void f(B&);

 C cinstance;

 f(cinstance); // ambiguous

    Same ambiguity.  But because function definitions are
taken seriously, that's considered an error.

    Another "too late to fix" problem.

    C++ has too many legacy problems like this.

    John Nagle

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Steven T. Hatton" wrote:
> Bob Bell wrote:
>
> > John Nagle wrote:
.
> >>      Misery is catching an exception at "catch ...".  All identifying
> >> information has been lost at that point.
> >
> > Not true; you can rethrow and catch to recover the exception type.
>
> If it's polymorphic, or otherwise selfdescriptive. I don't believe there is
> any way to extract type information from fundamental types at runtime.

When the exception is rethrown, it can be caught just as easily whether
it's a fundamental type or a polymorphic type; all that's needed is a
catch statement that actually specifies the type. The type information
isn't lost.

.
> My opinion is that the default behavior of the exception handling mechanism
> in C++ should produce a message describing as completely as possible any
> exception which unwound the stack to to point of popping main().  It would
> also be a good idea, if technically feasible, to require all exceptions to
> derive from std::exception by default, and provide a mechanism to override
> that restriction in order to support legacy, and esoteric code.

Your not supporting legacy code unless the new default behavior is the
same as the old behavior. If you provide some mechanism for invoking
the old behavior, then either old code or old build scripts/make files
have to be modified. That doesn't qualify as supporting legacy code.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:
>      Yes, we hit that because exception specifications aren't taken
> seriously.
>
>      Something similar to that happens when you write
>
>  struct A ();
>  struct B ();
>  struct C: public a, public B();
>
>  void f(A&);
>  void f(B&);
>
>  C cinstance;
>
>  f(cinstance); // ambiguous
>
>     Same ambiguity.  But because function definitions are
> taken seriously, that's considered an error.


Actually, there is a difference in this case.  Because the type of the
argument is known at compile time, that is why it is easy to consider
it an error.  However, in Stephan's example, the type of exception can
only be known at runtime, which makes it impossible to give a
compile-time error.  Unless we take the Java approach where all
exceptions need to be declared explicitly in the funtion signature -
but that seems to me like a bigger pain than its worth - I would much
rather it select the first possible match for handling the exception.

-shez-

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:
> Stephan Bergmann wrote:
>
>> Shezan Baig wrote:
>>
>>> John Nagle wrote:
>>>
>>>> This is perhaps the only place in C++ where order of statements affects
>>>> type matching.  Should it work that way?  Should unreachable catch
>>>> clauses like that be an error?  They're clearly detectable at
>>>> compile time.
>>>
>>>
>>>
>>>
>>>
>>> How about "catch block overload resolution" that behaves the same way
>>> as function overload resolution?
>>
>>
>>
>>   struct A {};
>>   struct B {};
>>   void f() throws (A, B);
>>
>>   try { f(); }
>>   catch (A &) { ... }
>>   catch (B &) { ... }
>>
>> would work fine, but as soon as someone adds
>>
>>   struct C: public A, public B {};
>>
>> and modifies the implementation of f to throw an instance of C, what
>> should happen?
>
>
>     Yes, we hit that because exception specifications aren't taken
> seriously.
>
>     Something similar to that happens when you write
>
>     struct A ();
>     struct B ();
>     struct C: public a, public B();
>
>     void f(A&);
>     void f(B&);
>
>     C cinstance;
>
>     f(cinstance); // ambiguous
>
>    Same ambiguity.  But because function definitions are
> taken seriously, that's considered an error.

IMO the ambiguities are quite different.  The former is a run-time
ambiguity, while the latter is a compile-time ambiguity.  The latter
ambiguity (the compile-time one) is resolved by not compiling the
program.  To resolve the former ambiguity (the run-time one), we would
have to bail out via std::terminate or some such at run-time, or define
some unambiguous order of catch clauses that is used when the proposed
"catch block overload resolution" fails due to an ambiguity---in which
case we would be back close to square one, the current, unambigiuos,
position-based scheme of selecting catch clauses...

Not sure what you mean with "exception specifications aren't taken
seriously" in this context, though.

-Stephan

>    Another "too late to fix" problem.
>
>    C++ has too many legacy problems like this.
>
>                 John Nagle

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On 2005-08-18 05:33, Stephan Bergmann wrote:
> Shezan Baig wrote:
>> John Nagle wrote:
>>
>>>This is perhaps the only place in C++ where order of statements
>>>affects type matching.  Should it work that way?  Should
>>>unreachable catch clauses like that be an error?  They're clearly
>>>detectable at compile time.
>>
>> How about "catch block overload resolution" that behaves the same way
>> as function overload resolution?
>
>    struct A {};
>    struct B {};
>    void f() throws (A, B);
>
>    try { f(); }
>    catch (A &) { ... }
>    catch (B &) { ... }
>
> would work fine, but as soon as someone adds
>
>    struct C: public A, public B {};
>
> and modifies the implementation of f to throw an instance of C, what
> should happen?

Well, it would already be an improvement if order mattered only in
cases where there are multiple "best matches".

-- Niklas Matthies

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Shezan Baig schreef:

> John Nagle wrote:
> > This is perhaps the only place in C++ where order of statements affects
> > type matching.  Should it work that way?  Should unreachable catch
> > clauses like that be an error?  They're clearly detectable at
> > compile time.
>
>
> How about "catch block overload resolution" that behaves the same way
> as function overload resolution?

Breaking change, of course. Function declarations are not distinguished
by declaration order. catch blocks are; in case of an "ambiguity" the
first
matching catch is used.

The fundamental reason is that there is only a single order of function
declarations in a TU. f(X) is defined either before or after f(Y).
However, a TU can and often will have multiple try{} blocks. One try{}
can have a catch(X) followed by a catch(Y) while the next has a
catch(Y)
before a catch(X). This difference alone is important enough to have
different rules.

HTH,
Michiel Salters

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:
>      Yes, we hit that because exception specifications aren't taken
> seriously.
>
>      Something similar to that happens when you write
>
>  struct A ();
>  struct B ();
>  struct C: public a, public B();
>
>  void f(A&);
>  void f(B&);
>
>  C cinstance;
>
>  f(cinstance); // ambiguous
>
>     Same ambiguity.  But because function definitions are
> taken seriously, that's considered an error.

Not the same at all. One's a static binding issue (which function to
call), the other is a dynamic issue (which exception is thrown). I know
you don't like the fact that exception specifications aren't checked
statically, but false analogies won't help.

>     Another "too late to fix" problem.

The lateness has nothing to do with the difficulty of fixing this. It
is simply a difficult problem with solution that pleases everyone.

Bob

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Steven T. Hatton" wrote:
> Bob Bell wrote:
>
> > John Nagle wrote:
> >>      I'm not sure what the original poster was really asking for.
> >> But it might be worthwhile to have stronger language suggesting
> >> that all exceptions be derived from class "std::exception".
> >>
> >>      Misery is catching an exception at "catch ...".  All identifying
> >> information has been lost at that point.
> >
> > Not true; you can rethrow and catch to recover the exception type.
>
> If it's polymorphic, or otherwise selfdescriptive. I don't believe there is
> any way to extract type information from fundamental types at runtime.

struct Foo {

};

void F()
{
   try {
      // ...
   }
   catch (...) {
      try {
         throw;
      }
      catch (int ex) {
         std::cout << "recovered an int.\n";
      }
      catch (const Foo& ex) {
         std::cout << "recovered a Foo.\n";
      }
   }
}

Works just fine, no polymorphism required.

> >>      But there's a problem with deriving exceptions from
> >> "std::exception".
> >
> > There are lots of problems with mandating that all exceptions be
> > derived from std::exception, among them the fact that tons of code
> > would break.
> >
> > Bob
>
> Mandating that they _must_ is not the same as strongly suggesting
> they /should/ derive from std::exception.

Saying they /should/ derive from std::exception is the same as saying
that there will be times when they /aren't/ derived from
std::exception, which means you can't depend on it, so what's the
point?

> Exception handling should be an
> aid to the programmer, not an additional challenge.

Agreed.

> My opinion is that the default behavior of the exception handling mechanism
> in C++ should produce a message describing as completely as possible any
> exception which unwound the stack to to point of popping main().

How do you propose doing that?

> It would
> also be a good idea, if technically feasible, to require all exceptions to
> derive from std::exception by default, and provide a mechanism to override
> that restriction in order to support legacy, and esoteric code.

I disagree; the only compelling reason I've ever heard for wanting all
exceptions to derive from std::exception is to deal with broken
runtimes that throw exceptions when undefined behavior occurs. I think
it's a much better idea to fix the broken runtime than to change the
standard to accomodate the broken runtime.

Bob

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Bob Bell wrote:
> John Nagle wrote:
> >     Another "too late to fix" problem.
>
> The lateness has nothing to do with the difficulty of fixing this. It
> is simply a difficult problem with solution that pleases everyone.

In case my typing mistakes aren't painfully obvious, that should be "It
is simply a difficult problem with NO solution that pleases everyone."

Bob

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

exception handling is generally advertised as one of the major features
of the languages such as c++. however due to the lack of
standardization in the c++ about the way the exceptions are being
handled/propagated, every compiler implements the exceptions handling
in a different way. As a result people working on the cross platform
solutions hardly use exception handling.

Most of the big softwares that are being developed are cross platform
and since exceptions are implemented in different these softwares
dosn't use exceptions for error recovery.

What i am thinking is to standardize the exceptions,if possible, so
that those developing the cross platform applications can use this very
good feature that is exceptions.


thanks
rt

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

<ravinderthakur@gmail.com> wrote:

>                               however due to the lack of
> standardization in the c++ about the way the exceptions are being
> handled/propagated, every compiler implements the exceptions handling
> in a different way.

It might help if you would be more specific about the aspects of
exception handling which are not specified, and you think they should be.

> What i am thinking is to standardize the exceptions,if possible, so
> that those developing the cross platform applications can use this very
> good feature that is exceptions.

Well, exceptions are standardized in a way (please refer to the
chapter 15 of the standard.)

--
Pavel

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

<ravinderthakur@gmail.com> wrote in message
news:1123763925.850895.253360@f14g2000cwb.googlegroups.com...
> exception handling is generally advertised as one of the major features
> of the languages such as c++. however due to the lack of
> standardization in the c++ about the way the exceptions are being
> handled/propagated, every compiler implements the exceptions handling

What exactly do you propose to standardize which is not covered by the
current standard? Compiler may have different implementations of stack
unwinding, exception prologs, etc., which doesn't impact their ability to
comply with the standard.

> in a different way. As a result people working on the cross platform
> solutions hardly use exception handling.

What people? Why? Again, I don't understand what cross-platform problems you
are referring. Our company has products released on  around 10 different
paltforms, and we don't have any problems with using exceptions.

- gene

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

ravinderthakur wrote:
>
> exception handling is generally advertised as one of the major
> features of the languages such as c++. however due to the lack of
> standardization in the c++ about the way the exceptions are being
> handled/propagated, every compiler implements the exceptions
> handling in a different way.

I don't know who told you this, but it's not true.


> As a result people working on the cross platform solutions hardly
> use exception handling. Most of the big softwares that are being
> developed are cross platform and since exceptions are implemented
> in different these softwares dosn't use exceptions for error
> recovery.

No.  When I develop cross platform software, I don't use exception handling
because old compilers don't support it at all (there were C++ compilers even
before there was a C++ standard).  The compilers that do support exceptions,
follow the standard, since exception handling *is* standardised.


> What i am thinking is to standardize the exceptions

This is already the case.


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

realnc@hotmail.com ("Nikos Chantziaras") writes:

> ravinderthakur wrote:
>>
>> exception handling is generally advertised as one of the major
>> features of the languages such as c++. however due to the lack of
>> standardization in the c++ about the way the exceptions are being
>> handled/propagated, every compiler implements the exceptions
>> handling in a different way.
>
> I don't know who told you this, but it's not true.

Some compilers implement EH in the same way, but it's true as a rule
that given any two compilers, the EH implementation may be different.
>
>> As a result people working on the cross platform solutions hardly
>> use exception handling. Most of the big softwares that are being
>> developed are cross platform and since exceptions are implemented
>> in different these softwares dosn't use exceptions for error
>> recovery.
>
> No.  When I develop cross platform software, I don't use exception handling
> because old compilers don't support it at all (there were C++ compilers even
> before there was a C++ standard).  The compilers that do support exceptions,
> follow the standard, since exception handling *is* standardised.

The *behavior* of exception handling is standardized.  In general, the
*binary interface* for exception handling is not standardized, except
on a few platforms that adopted
refspecs.freestandards.org/elf/IA64-SysV-psABI.pdf

It's generally been the position of the C++ committee that ABI
specification/standardization isn't our domain, and it should be left
to those who control the various platforms.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.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://www.jamesd.demon.co.uk/csc/faq.html                       ]

David Abrahams wrote:
> realnc@hotmail.com ("Nikos Chantziaras") writes:
>
>> ravinderthakur wrote:
>>
>>> exception handling is generally advertised as one of the major
>>> features of the languages such as c++. however due to the lack of
>>> standardization in the c++ about the way the exceptions are
>>> being handled/propagated, every compiler implements the
>>> exceptions handling in a different way.
>>
>> I don't know who told you this, but it's not true.
>
> Some compilers implement EH in the same way, but it's true as a rule
> that given any two compilers, the EH implementation may be different.

Yes, the implementation is different.  But the usage/semantics of C++ EH
is the same (it's part of the language).  That's what the OP was talking
about.  He/she wrote:

> due to the lack of standardization in the c++ about the way the
> exceptions are being handled/propagated, every compiler implements
> the exceptions handling in a different way.

The standard very well defines how exceptions are handled and propagated.


>>> As a result people working on the cross platform solutions hardly
>>> use exception handling. Most of the big softwares that are being
>>> developed are cross platform and since exceptions are
>>> implemented in different these softwares dosn't use exceptions
>>> for error recovery.
>>
>> No.  When I develop cross platform software, I don't use exception
>> handling because old compilers don't support it at all (there were
>> C++ compilers even before there was a C++ standard).  The compilers
>> that do support exceptions, follow the standard, since exception
>> handling *is* standardised.
>
> The *behavior* of exception handling is standardized.  In general,
> the *binary interface* for exception handling is not standardized,

I wanted to point out that programs can assume that EH works the same on
every compiler that actually supports EH.  Binary interfaces are of no
concern to programs.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Nikos Chantziaras wrote:

> David Abrahams wrote:
>
>> realnc@hotmail.com ("Nikos Chantziaras") writes:
>>
>>> ravinderthakur wrote:
>>>
>>>> exception handling is generally advertised as one of the major
>>>> features of the languages such as c++. however due to the lack of
>>>> standardization in the c++ about the way the exceptions are being
>>>> handled/propagated, every compiler implements the exceptions
>>>> handling in a different way.

     I'm not sure what the original poster was really asking for.
But it might be worthwhile to have stronger language suggesting
that all exceptions be derived from class "std::exception".

     Misery is catching an exception at "catch ...".  All identifying
information has been lost at that point.

     But there's a problem with deriving exceptions from
"std::exception".

namespace CEGUI;
class Exception: public std::exception {
.
};

.

try
     {
         // do CEGUI and std-c++ stuff in here
     }
     catch (std::exception& exc)
     {
         // Recover from std usage issue.
     }
     catch (CEGUI::Exception& exc)
     {
         // Recover from CEGUI issue
     }

.
     CEGUI::Exception foo;
     throw foo;

Which "catch" gets that exception?  The less restrictive
clause is first, and std::exception will match, so it
looks like CEGUI::Exception will never be matched, and
is thus unreachable.

Here's a project that hit that problem, and decided not to use
std::exception because of it.

http://www.cegui.org.uk/modules/newbb/viewtopic.php?topic_id=900&post_id=5220

This is perhaps the only place in C++ where order of statements affects
type matching.  Should it work that way?  Should unreachable catch
clauses like that be an error?  They're clearly detectable at
compile time.

    John Nagle
    Animats

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:
> This is perhaps the only place in C++ where order of statements affects
> type matching.  Should it work that way?  Should unreachable catch
> clauses like that be an error?  They're clearly detectable at
> compile time.


How about "catch block overload resolution" that behaves the same way
as function overload resolution?

-shez-

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Pavel Kuznetsov" wrote:
> <ravinderthakur@gmail.com> wrote:
>
> >                               however due to the lack of
> > standardization in the c++ about the way the exceptions are being
> > handled/propagated, every compiler implements the exceptions handling
> > in a different way.
>
> It might help if you would be more specific about the aspects of
> exception handling which are not specified, and you think they should be.
>
> > What i am thinking is to standardize the exceptions,if possible, so
> > that those developing the cross platform applications can use this very
> > good feature that is exceptions.
>
> Well, exceptions are standardized in a way (please refer to the
> chapter 15 of the standard.)
Is it possible he is referring to the issue where certain systems use
the C++ exception handling mechanism to deal with OS or hardware
errors. This creates absolute havoc, because the behaviour of:

int wibble(int *a) throw()
{
    return *a;
}

int fred = wibble(0)

is going to be strangely different on different platforms (I know, it's
the coders fault for writing code like that - but presumably there may
be other reasons why the O/S might decide to deal with some wacky error
by throwing an exception?)

Certainly this behaviour is enough to generate a few questions /
answers in various C++ FAQs.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]