Re: on the matter of exceptions
On Mar 8, 10:25 pm, Jonathan Mcdougall <jonathanmcdoug...@gmail.com>
wrote:
Good day.
I've written a (rather long) article on error handling on general,
particularly
on assertions, exceptions and return values. It is hosted on my
personal blog
on blogspot, not because that blog is interesting, but because I have
nowhere
else to post it.
http://mcdougalljonathan.blogspot.com/2011/03/on-matter-of-exceptions...
The four sections of the article are as follows:
. Exceptions vs. return values
. Throwing objects vs. throwing fundamental types
. Exception hierarchies vs. embedding values
. Lack of a finally construct
and here are the conclusions of the article:
"Assertions, return values and exceptions provide a way of signaling
logic
errors (coding mistakes), runtime errors (part of the normal execution
flow) and
exceptional cases (that break the normal execution flow). Using them
together
allows the normal execution path to be free of error-checking while
still being
able to distinguish between the different outcomes of an operation.
Exceptional
cases are propagated until a function knows how to deal with them.
In my mind there's another type of error, which I'd call "corruption".
That refers to coding mistakes that cause memory violation
(specifically write to non-owned area in memory like uninitialized
pointer or bound breach). These where not previously verified by
assertion, because such an assertion (e.g. bound check) would have
failed and not let the violation occur. The special problem with this
kind is that the code may have corrupted any other data of other
structures in the process, and generally, all current values in the
process memory cannot be trusted.
The practical point of this difference is as some other posts
suggested that sometimes an assertion could evolve into a throw, so
that a certain wrong calculation can be skipped somehow, and continue
the global task without it. When a corruption error happens there's
never a possibility to skip anything, it is always a show stopper,
because the global task may have been corrupted.
However, it is important to clearly explain the case when an assertion
failure (that always implies a bug in the code) could evolve into such
a throw. The point is that some global task could skip the wrong
calculation. However, it raises the question: if you already know
there's a bug in the code as this assertion failure implies, then how
can you trust any other result, that such a bug could cause, but maybe
the assertion doesn't catch. In other words, most assertions fail *if*
there is a bug in the code that affected the currect calculation, but
when they succeed, it doesn't neccessarily imply that such a bug
didn't affect the calculation.
But in some special cases, it could work. Suppose there's some complex
calculation done by function F(x) (for example break an integer to
primary components). But there's also already a function G(y) which is
simple (relatively non-complex) and is the inverse of F (s.t.
G(F(x))==x).
Then one could implement F:
Result F( Input x )
{
//some complex computation here which results with:
Result const y( ... );
ASSERT( G(y) == x ); //this is a relatively short computation.
return y;
}
This is an "ultimate assertion", it means that it passes *if and only
if* the calculation is correct. So if it passes one can certainly
trust the result. Such an assertion could evolve to a throw:
Result F( Input x )
{
//some complex computation here which results with:
Result const y( ... );
if( G(y) == x ) //this is a relatively short computation.
{
throw BugException( "bug in my code" );
}
return y;
}
This can be caught by the caller task, and insuccessful calculations
can be skipped, while trusting that the calculations that completed
were not affected by any bugs.
* we are looking for bugs in the code for F, the question of whether
there could be a bug in G is valid, but also a separate question - G
has to be debugged for its own sake.
itaj
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]