Re: Proposal: A block between "try" and "catch".
On Jun 5, 4:22 am, "Adam H. Peterson" <alpha.eta...@gmail.com> wrote:
I have an exception handling proposal for the language.
There's a good chance that:
1. Something almost as good is implementable as a library with scary-clever
techniques already in the standard language.
2. Something just as good will be implementable as a library once you can use
a conforming implementation of C++ 0x.
3. Your proposed language extension will not gain support.
try {
T var;
} <---- Every other closing curly brace in C++ destructs var.
catch void . . .
4. If your language extension is accepted, you will still have
to use (1) or (2) for the next 5 - 10 years.
But perhaps there's something good for (1) or (2) . . .
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().
Ideas:
* Make the other code in your project handle the range_error exception, so
you can just propagate it upwards.
* Basic re-org one:
// an anonymous block keeps same lifetime of Object instance.
{
some_smart_pointer<Object> ob_ptr;
try
{
ob_ptr.reset(new Object("data"));
}
catch (range_error e) {
// as before.
}
if (ob_ptr)
{
Object & ob = *ob_ptr; // For the remainder of this block 'ob' looks
// almost exactly like it did before.
do_something_else(ob, "other data");
}
}
Obvious drawbacks:
More verbose.
Additional heap allocation.
* Boost::optional with in-place factories avoids need for
heap alloaction Re-org two:
{
boost::Optional<Object> ob_opt;
try
{
ob_opt = boost::in_place("data"); // I think this should work . . .
The rest is pretty much the same as re-org one.
Obvious drawbacks:
More verbose.
Boost::optional and in_place are not perfect for everything.
* You mentioned conditional rethrowing. Looks like that might macro-ize well!
Why wouldn't this work?
Re-org three:
EXTENDED_TRY_MACRO // for (bool uniqueName = true; uniqueName; uniqueName = false) try
{
Object ob("data"); // May throw range_error
STOP_CATCHING_MACRO // uniqueName = false;
do_something_else(ob, "other data");
}
catch (range_error & e) // Note: now catching by reference
{
EXTENDED_CATCH_MACRO // if (!uniqueName) throw;
// as before
}
Benefits:
Scope of ob remains natural.
Obvious drawbacks:
Everyone knows macros are bad.
- Marsh
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]