Re: Necessity of multi-level error propogation
Tony wrote:
[skip] If the goal was to see what
alternatives develop (read, R&D), banning exception use would be not stupid,
but facilitating. "Double blind" experiment or similar.
If it's for a research or teaching project, it can certainly be
interesting. If only to show how painful error management could be
in the good 'ol days of C :)
I don't see that as a rule of thumb anymore since error codes can be
reliably propogated up the stack pretty easily without "jumping and
introducing alternative unwind mechanisms".
Reliability:
One common problem in C, is that programers tend to forget to check
and/or
propagate errors. Since C++ has more functionalities, it can give
some help
that doesn't exist in C. You could start by looking at Alexandrescu's
mandatory error codes (http://www.ddj.com/cpp/184401917 [one third
down
the page])
Jumping:
In C, it's common to use early return from a function when
encountering a
error, which is a kind of jump. If the function needs to acquire a
resource
at the beginning and release it at the end, the idiomatic
implementation
uses gotos:
error_code func(void)
{
error_code res = no_error;
if (!acquire_resource) {
return error_out_of_resource;
}
if (foo()==failed) {
res = an_error_code;
goto cleanup;
}
if (bar()==failed) {
res = another_error_code;
goto cleanup;
}
cleanup:
release_resource();
return res;
}
Using a guard can probably simplify the code, but you would have to
keep the
hand-crafted test for resource acquisition, since you don't want the
guard
constructor to throw an exception. Something like the following can
be done:
error_code func()
{
if (!acquire_resource()) return error_out_of_resource;
Guard guard(release_resource);
if (!foo()) return an_error_code;
if (!bar()) return another_error_code;
return no_error;
}
As a comparison, in C++ with exceptions, you would have:
void func()
{
Guard guard(acquire_resource, release_resource); // may throw
foo(); // may throw
bar(); // may throw
}
Alternative unwind mechanisms
Even C has a stack unwinding mechanism, using setjmp and longjmp
(clunkier than exceptions, I think). And although I've never used it,
its mere existence makes me think that there are circumstances where
stack unwinding is clearly better than any alternative.
Yes, constructors and overloaded operators MAY be an issue. But maybe that's
just a matter of coding style: if you choose to architect software using
RAII as a (or THE) design construct, then you will constantly be trying to
catch exceptions from constructors. It may be one of those "if it hurts when
you do that, don't do that" things.
You can avoid exceptions in constructors by doing two-stage
initialization:
- the constructor doesn't execute any code that can fail, that means
that
the constructed object is often in an invalid state and therefore the
destructor needs to handle this special case.
- the class has an initialization function that can return an error
code.
Your code could look like this:
Foo *foo = new Foo();
if (!foo) { // not standard, but some compilers have a switch for
that
return error_out_of_memory;
}
error_code err = foo->init(x, y, z);
if (err != no_error) {
delete foo;
return err;
}
// go on with non-exceptional code path
Note that you've traded "constantly trying to catch exceptions" for
"constantly testing error code". OTOH, it may be possible to simplify
the code by using a fallible class (an example of a fallible class:
http://www.atnf.csiro.au/computing/software/casacore/casacore-0.4.0/doc/html/classcasa_1_1Fallible.html)
or by keeping an error code in the Foo class and doing an early return
in every member if the error is set.
As a comparison, in C++ with exceptions, you would have:
Foo *foo = new Foo(x, y, z); // may throw
// go on with non-exceptional code path
HTH