using exceptions as a "deep" return

[Mark P]

I'm implementing an algorithm and the computational flow is a somewhat
deep. That is, fcn A makes many calls to fcn B which makes many calls
to fcn C, and so on. The return value of the outermost fcn is a boolean
and there are certain places within the inner functions where it may
become apparent that the return value is false. In this case I'd like
to halt the computation immediately and return false.

My current approach is to have any of the inner functions throw an
exception if the return value is ever determined early like this. Then
within fcn A I'll catch the exception and return false. Is this a good
approach or is there a more C++ way to handle this? It's sort of a
glorified goto, but it does get the job done.

On a related note, if an exception is never thrown, is there any
performance penalty to enclosing a block of code within a try-catch
block. The exceptional case above should be rare and I don't want to
hurt the common case by doing this.

Thanks,
Mark

[Alf P. Steinbach]

* Mark P:

I'm implementing an algorithm and the computational flow is a somewhat
deep. That is, fcn A makes many calls to fcn B which makes many calls
to fcn C, and so on. The return value of the outermost fcn is a boolean
and there are certain places within the inner functions where it may
become apparent that the return value is false. In this case I'd like
to halt the computation immediately and return false.

My current approach is to have any of the inner functions throw an
exception if the return value is ever determined early like this. Then
within fcn A I'll catch the exception and return false. Is this a good
approach or is there a more C++ way to handle this?
In some rare cases it can be a good approach.

It's sort of a
glorified goto, but it does get the job done.

On a related note, if an exception is never thrown, is there any
performance penalty to enclosing a block of code within a try-catch
block. The exceptional case above should be rare and I don't want to
hurt the common case by doing this.

Measure -- that's the /only/ reasonable advice.

However, also see "ISO/IEC TR 18015:2006 C++ Performance - draft TR" at
<url: http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf>.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Phlip]

Mark P wrote:

I'm implementing an algorithm and the computational flow is a somewhat
deep. That is, fcn A makes many calls to fcn B which makes many calls to
fcn C, and so on. The return value of the outermost fcn is a boolean and
there are certain places within the inner functions where it may become
apparent that the return value is false. In this case I'd like to halt
the computation immediately and return false.

My current approach is to have any of the inner functions throw an
exception if the return value is ever determined early like this. Then
within fcn A I'll catch the exception and return false. Is this a good
approach or is there a more C++ way to handle this? It's sort of a
glorified goto, but it does get the job done.
Did you measure how fast this implementation is, compared to a version that
returns the value back up the stack? Both activities must unwind the stack,
so (for some C++ implementations ) returning the value might be faster.

You need a better reason than "I don't feel like typing lots of return
statements" to violate the guideline in /C++ Coding Standards/ by Sutter &
Alexandrescu called "Use Exceptions for Exceptional Situations" (IIRC).
On a related note, if an exception is never thrown, is there any
performance penalty to enclosing a block of code within a try-catch block.
The exceptional case above should be rare and I don't want to hurt the
common case by doing this.

This is a topic of many discussions, including philosophical ones over
whether a language should support exceptions at all. Google will find reams.
A more important question: Will anyone ever care if this routine is fast, or
are you just indulging in Creative Coding?

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!

[Mark P]

Phlip wrote:

Mark P wrote:

I'm implementing an algorithm and the computational flow is a somewhat
deep. That is, fcn A makes many calls to fcn B which makes many calls to
fcn C, and so on. The return value of the outermost fcn is a boolean and
there are certain places within the inner functions where it may become
apparent that the return value is false. In this case I'd like to halt
the computation immediately and return false.

My current approach is to have any of the inner functions throw an
exception if the return value is ever determined early like this. Then
within fcn A I'll catch the exception and return false. Is this a good
approach or is there a more C++ way to handle this? It's sort of a
glorified goto, but it does get the job done.

Did you measure how fast this implementation is, compared to a version that
returns the value back up the stack? Both activities must unwind the stack,
so (for some C++ implementations ) returning the value might be faster.

You need a better reason than "I don't feel like typing lots of return
statements" to violate the guideline in /C++ Coding Standards/ by Sutter &
Alexandrescu called "Use Exceptions for Exceptional Situations" (IIRC).

It was this very phrase that prompted my question. I'm not sure whether
or not my situation qualifies as exceptional, but I'll consider this
further.

On a related note, if an exception is never thrown, is there any
performance penalty to enclosing a block of code within a try-catch block.
The exceptional case above should be rare and I don't want to hurt the
common case by doing this.

This is a topic of many discussions, including philosophical ones over
whether a language should support exceptions at all. Google will find reams.
A more important question: Will anyone ever care if this routine is fast, or
are you just indulging in Creative Coding?

Thanks for the advice. Yes, speed is critically important. Think
geometry processing for large scale semiconductor designs. I don't
really care how fast the exception handling is, within reason, since it
should be rare. My question was motivated by style and coding practice
concerns.

As far as actual performance issues, I only wonder whether code which
supports exception handling, though an exception is not actually thrown,
will suffer any performance degradation. My instinct is not, since lots
of things could throw runtime exceptions and I never give these a
thought as far as affecting performance, but then as you can see I don't
really know.

[Mark P]

Alf P. Steinbach wrote:

* Mark P:

I'm implementing an algorithm and the computational flow is a somewhat
deep. That is, fcn A makes many calls to fcn B which makes many calls
to fcn C, and so on. The return value of the outermost fcn is a
boolean and there are certain places within the inner functions where
it may become apparent that the return value is false. In this case
I'd like to halt the computation immediately and return false.

My current approach is to have any of the inner functions throw an
exception if the return value is ever determined early like this.
Then within fcn A I'll catch the exception and return false. Is this
a good approach or is there a more C++ way to handle this?

In some rare cases it can be a good approach.

It's sort of a glorified goto, but it does get the job done.

On a related note, if an exception is never thrown, is there any
performance penalty to enclosing a block of code within a try-catch
block. The exceptional case above should be rare and I don't want to
hurt the common case by doing this.

Measure -- that's the /only/ reasonable advice.

However, also see "ISO/IEC TR 18015:2006 C++ Performance - draft TR" at
<url: http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf>.

Great link, thanks.

[Ian Collins]

Mark P wrote:

As far as actual performance issues, I only wonder whether code which
supports exception handling, though an exception is not actually thrown,
will suffer any performance degradation. My instinct is not, since lots
of things could throw runtime exceptions and I never give these a
thought as far as affecting performance, but then as you can see I don't
really know.

As Phlip said, this has been debated at length here. In my experience,
with my compilers, you are correct.

--
Ian Collins.

[Pete Becker]

Mark P wrote:

As far as actual performance issues, I only wonder whether code which
supports exception handling, though an exception is not actually thrown,
will suffer any performance degradation.

The answer is yes. While it's theoretically possible to write exception
handling code that does not inject any additional opcodes when no
exceptions are thrown, that's not all there is to performance. Such
implementations need data tables that must be available at runtime. That
means a bigger footprint, higher disk usage, maybe slower startup. And,
of courese, if you're not using an implementation that does that, you
may well have added code even when there no exceptions are thrown. More
important, if an exception is thrown, typical execution time is several
orders of magnitude slower than an ordinary return.

--

Pete Becker
Roundhouse Consulting, Ltd.

[Phlip]

Mark P wrote:

It was this very phrase that prompted my question. I'm not sure whether
or not my situation qualifies as exceptional, but I'll consider this
further.
Your situation is the normal control flow, not the exceptional
(unpredictable, uncorrectable, and risky) control flow.
Thanks for the advice. Yes, speed is critically important.
Ah, then you have lots of unit tests, and you can time them. And when they
reveal bottlenecks you can tune the code and still pass all the tests.
Think geometry processing for large scale semiconductor designs. I don't
really care how fast the exception handling is, within reason, since it
should be rare. My question was motivated by style and coding practice
concerns.

Then the most important resource to optimize is programmer time. Write the
simple code, not the clever-clever code.

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!

[Rolf Magnus]

Mark P wrote:

I'm implementing an algorithm and the computational flow is a somewhat
deep. That is, fcn A makes many calls to fcn B which makes many calls
to fcn C, and so on. The return value of the outermost fcn is a boolean
and there are certain places within the inner functions where it may
become apparent that the return value is false. In this case I'd like
to halt the computation immediately and return false.

My current approach is to have any of the inner functions throw an
exception if the return value is ever determined early like this. Then
within fcn A I'll catch the exception and return false. Is this a good
approach or is there a more C++ way to handle this? It's sort of a
glorified goto, but it does get the job done.

Stroustrup has a similar example in TC++PL:

void fnd(Tree* p, const string& s)
{
if (s == p->str) throw p;
if (p->left) fnd(p->left, s);
if (p->right) fnd(p->right, s);
}

Tree* find(Tree* p, const string& s)
{
try {
fnd(p, s);
}
catch (Tree* q)
{
return q;
}
return 0;
}

[Mark P]

Pete Becker wrote:

Mark P wrote:

As far as actual performance issues, I only wonder whether code which
supports exception handling, though an exception is not actually
thrown, will suffer any performance degradation.

The answer is yes. While it's theoretically possible to write exception
handling code that does not inject any additional opcodes when no
exceptions are thrown, that's not all there is to performance. Such
implementations need data tables that must be available at runtime. That
means a bigger footprint, higher disk usage, maybe slower startup. And,
of courese, if you're not using an implementation that does that, you
may well have added code even when there no exceptions are thrown. More
important, if an exception is thrown, typical execution time is several
orders of magnitude slower than an ordinary return.

Thanks. Your comments and others have convinced me to choose a
different route and I have changed my code to avoid this usage.

I'm curious about one point you made, which is that an implementation
may have added code even when no exceptions are thrown. Wouldn't that
same code be generated anyway since all sorts of functions not written
by me may also throw exceptions?

Mark