Topic: exceptional problems


Author: "Sergey P. Derevyago" <non-existent@iobox.com>
Date: Fri, 31 Aug 2001 17:30:29 GMT
Raw View
There is some tricky issues with EH: you can not be sure that catch(B&)
clause can catch a D object (where B is indirectly publically derived from
B):
-----------------------------------8<-----------------------------------
#include <stdio.h>

struct B {};
struct B1 : B {};
struct B2 : B {};
struct D : B1, B2 {};  // D() has two B() subobjects

void f() { throw D(); }

int main()
{
 try { f(); }
 catch (B& b) { puts("B&"); }  // passed
 catch (D& d) { puts("D&"); }  // really works _after_ B&!!!
}
-----------------------------------8<-----------------------------------
So:
1. The phrase "Matherr handler will catch exceptions of type Matherr and of
all types publicly derived from Matherr" from 15.3.p4 example:

 try {
     g();
 }
 catch (Overflow oo) {
       // ...
 }
 catch (Matherr mm) {
      // ...
 }

is incorrect: one can create a Matherr exception that can leak.

2. The phrase "... 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" from 15.3.p5 is incorrect: such handlers can be
easily executed.
--
         With all respect, Sergey.          http://cpp3.virtualave.net/
         mailto : ders at skeptik.net

---
[ 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.research.att.com/~austern/csc/faq.html                ]





Author: Ron Natalie <ron@sensor.com>
Date: Fri, 31 Aug 2001 18:11:14 GMT
Raw View

> 1. The phrase "Matherr handler will catch exceptions of type Matherr and of
> all types publicly derived from Matherr" from 15.3.p4 example:

Should have the word "unambiguously" added to publically.

>
> 2. The phrase "... 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" from 15.3.p5 is incorrect: such handlers can be
> easily executed.
> --

This is OK.  It doesn't say that all such handlers will be never executed.
It's just an example of a way that might be attained.

---
[ 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.research.att.com/~austern/csc/faq.html                ]