Re: Proposal: A block between "try" and "catch".
On Jun 6, 1:55 am, peter koch larsen <peter.koch.lar...@gmail.com>
wrote:
On 5 Jun., 11:22, "Adam H. Peterson" <alpha.eta...@gmail.com> wrote:
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.
}
What is wrong with:
Object ob("data"); // May throw range_error
try {
// 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.
}
I think Adam was looking for the exact opposite: to catch the
exceptions originated in the constructor and not the exceptions from
do_something_else().
?
This handles exactly what you want to handle.
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?
I believe this is obfuscation. A catch block that sometimes does not
catch anything is not something I would recommend.
I also find this proposal a little bit awkward, but I must say that I
would liked a solution to Adam's problem in the language.
The way I see it, this is a scoping problem. Normally, I would have
tried to wrote the program in the following way:
void f()
{
try {
Object ob("data"); // May throw range_error
} catch (range_error e) {...}
// This may also throw range_error,
// but I don't want to catch this one
do_something_else(ob, "other data"); // Ooops, "ob" doesn't
exist!!!
}
Now, to solve this problem (let exceptions from do_something_else() be
thrown outside f), I need to make a real complex logic:
void f()
{
bool rethrowRangeError = false;
try {
Object ob("data"); // May throw range_error
try {
// This may also throw range_error,
// but I don't want to catch this one
do_something_else(ob, "other data"); // Ooops, "ob"
doesn't exist!!!
} catch (range_error e) {
rethrowRangeError = true;
throw;
}
} catch (range_error e)
{
if ( rethrowRangeError ) throw;
else {...}
}
}
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]