Re: Proposal: A block between "try" and "catch".

From:

Alberto Ganesh Barbati <AlbertoBarbati@libero.it>

Newsgroups:

comp.lang.c++.moderated

Date:

Fri, 6 Jun 2008 00:29:00 CST

Message-ID:

<SR_1k.3484$Ca.13072@twister2.libero.it>

Adam H. Peterson ha scritto:

I have an exception handling proposal for the language.

Sometimes I want to check a small block of code for an exception, but
I want the recovery point to be lower in the function than I want the
try block to guard against. For example, I may have something like:

try {
     Object ob("data"); // May throw range_error

     // This may also throw range_error,
     // but I don't want to catch this one
     do_something_else(ob, "other data");

} catch (range_error e) {
     // handle the failed construction of ob.
}

The key here is that if ob fails to construct, I don't want to execute
do_something_else(), so I can't put the catch block next to the
construction. (This is especially true since that would shorten ob's
lifetime.) However, do_something_else() throws exceptions of the same
type as the ones I'm interested in from Object().

You can write:

   std::auto_ptr<Object> ob;

   try
   {
     ob.reset(new Object("data"));
   }
   catch (range_error e)
   { ... }

   if (ob)
   {
     do_something_else(*ob, "other data");
   }

If you don't like the heap allocation you may consider boost::optional
as a replacement of std::auto_ptr.

I'd like to propose an extension to the try{} syntax that allows
specifying a code region inside the try{} where exceptions aren't
caught. In the interest of not introducing new keywords, I'd suggest
a syntax something like this:

try {
     // Code where exceptions are caught
     T var;
} catch void {
     // The catch blocks below don't apply to this code.
     // However, it is an extension of the above scope,
     // so var is still visible here.
     var.still_visible();
} catch (E) {
     // This block is entered if T() throws E,
     // but not if still_visible() throws E.
     // That exception would propagate.
}

Anyway, I've had to work around this usage scenario frequently enough
that I think it might be worthwhile to extend the language to handle
it. But what do you all think?

For what my opinion is worth (which is not very much) this syntax is
unacceptable, because it would be the first case in the whole language
where the lifetime of a local variable defined within a block does not
end at the end of that block. This would be very confusing... Not that I
like or endorse this extension, but at least this syntax:

try {
      // Code where exceptions are caught
      T var;

      catch void {
        // Exception thrown from this block are not caught
        var.still_visible();
      }

} catch (E) {
      // This block is entered if T() throws E,
      // but not if still_visible() throws E.
      // That exception would propagate.
}

is way more readable. I'm not a compiler writer, but I have the gut
feeling that it won't be so easy to implement...

Just my opinion,

Ganesh

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]