Paragraph seven of "15.1 Throwing an exception" [except.throw]
discusses which exception is thrown by a throw-expression with no operand.

May an expression which has been "finished (15.1p7)" by an inner catch block
be rethrown by an outer catch block?

catch(...)    // Catch the original exception
{
  try{ throw; }    // rethrow it at an inner level (in reality this is
probably inside a function)
  catch (...)
  {
  }   // Here, an exception (the original object) is "finished" according to
15.1p7 wording

  // 15.1p7 says that only an unfinished exception may be rethrown.
  throw;    // Can we throw it again anyway?  It is certainly still alive
(15.1p4).
}

I believe this is ok, since the paragraph says that the exception is
finished when the "corresponding" catch clause exits.  However since we have
two clauses, and only one exception, it would seem that the one exception
gets "finished" twice.



---
[ 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              ]

Bill Wade wrote:
>
> Paragraph seven of "15.1 Throwing an exception" [except.throw]
> discusses which exception is thrown by a throw-expression with no operand.
>
> May an expression which has been "finished (15.1p7)" by an inner catch block
> be rethrown by an outer catch block?
>
> catch(...)    // Catch the original exception
> {
>   try{ throw; }    // rethrow it at an inner level (in reality this is
> probably inside a function)
>   catch (...)
>   {
>   }   // Here, an exception (the original object) is "finished" according to
> 15.1p7 wording
>
>   // 15.1p7 says that only an unfinished exception may be rethrown.
>   throw;    // Can we throw it again anyway?  It is certainly still alive
> (15.1p4).
> }
>
> I believe this is ok, since the paragraph says that the exception is
> finished when the "corresponding" catch clause exits.  However since we have
> two clauses, and only one exception, it would seem that the one exception
> gets "finished" twice.

15.1 p7 says explicitly that "The exception thrown is the one most
recently caught and not finished." Since the one caught by the innermost
handler has finished, it can't be the one thrown. There isn't any other
exception available to be re-thrown, so I don't think the second 'throw'
is legal.

---
[ 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              ]

in article 89ed5u$8ck@library1.airnews.net, Bill Wade at
bill.wade@stoner.com wrote on 2/29/00 6:04 AM:

> I believe this is ok, since the paragraph says that the exception is
> finished when the "corresponding" catch clause exits.  However since we have
> two clauses, and only one exception, it would seem that the one exception
> gets "finished" twice.

FWIW, I agree that your interpretation is the only one that makes sense.
Perhaps this is really a non-issue because catch(...) implicitly catches "by
reference", and the reference is in fact the object which is finished (not
the exception thrown)... but I'm way out on a limb here; I haven't bothered
to look at the standard language for this.

-Dave

---
[ 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              ]