Prev: Summary of C++0x Feature Availability
Next: Detecting a static member variable
From: Nevin :-] Liber on 6 Mar 2010 15:31
In article
<ebd4c02a-99cc-41c1-8f80-c6baa8a35f1a(a)o3g2000yqb.googlegroups.com>,
"WalterHoward(a)gmail.com" <walterhoward(a)gmail.com> wrote:

> Bad Use: Don't "half-use" exceptions
>
> Many programmers, and even the standard library, have the idea that
> exceptions should be reserved for "fatal" errors only. They still use
> old style return codes in many functions. There is a huge flaw in the
> logic of this approach.

I'm one of those many programmers, and I see a huge flaw in only using
exceptions (as well as a huge flaw in only using return codes, such as
espoused at <http://www.joelonsoftware.com/items/2003/10/13.html>).

The analogy I like to give is that using return codes is like driving on
surface streets, while using exceptions is like taking the expressway.
Each has an appropriate use.

> A failure to perform its function is fatal to
> the function involved.

You are assuming a function even knows that it failed. Functions
usually have no idea why they are being called.

Take std::find. Is it really "failure" if it returns its second
parameter? Doesn't it really depend on whether or not the caller
expects the element to be in the range being searched? What if the
caller looked like:

// Bug if element is still in c
assert(std::find(c.begin(), c.end(), element) == c.end());

If std::find, instead of returning c.end() to indicate the element isn't
in the range, threw find_exception, the code would be a bit messier, as
in:

#ifndef NDEBUG
// Bug if element is still in c
try { std::find(c.begin(), c.end(), element); assert(false); }
catch (find_exception&) {}
#endif

The inversion of having failure detection inside a try block and having
success be the empty catch block makes this code much harder to
understand, yet there really is no way around it if you are using
exceptions instead of return codes, because the callee, not the caller,
has to decide what is "success" and what is "failure".

Things that are expected to be handled directly by the caller are
usually sent in return codes; things that are expected to be handled at
a much higher level are usually sent via exceptions (at least in the
code that I have influence over).

--
Nevin ":-)" Liber <mailto:nevin(a)eviloverlord.com> 773 961-1620

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Mathias Gaunard on 7 Mar 2010 08:29
On 7 mar, 14:50, "A. McKenney" <alan_mckenn...(a)yahoo.com> wrote:
> I'm one of those programmers who rarely if ever uses exceptions.
>
> The biggest reason is that exceptions are expensive. I've spent
> a lot of time replacing exceptions with error returns (or
> error work-arounds), because we could not afford the time spent
> handling them. My applications handle real-time data, and if
> your program is slow, you drop data. It is a bad trade-off to
> handle a little bit of bad data elegantly while dropping lots
> of good data to do so.

If errors happen often enough that it has such effects, then obviously
it is part of the program logic to deal with it and whether there is
an error or not should be part of the state of the subsystem in
question.
Exceptions are for exceptional situations (things that shouldn't
happen in a "normal" run of your program), that are handled separately
from normal control flow.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Joshua Maurice on 8 Mar 2010 12:20
On Mar 8, 2:01 pm, "Nevin :-] Liber" <ne...(a)eviloverlord.com> wrote:
> In article
> <e10fe54e-1e99-4658-bce5-152de76d9...(a)t17g2000prg.googlegroups.com>,
> Joshua Maurice <joshuamaur...(a)gmail.com> wrote:
>
> > It's generally accepted that throwing and catching exceptions in C++
> > on common desktops and servers is several magnitudes slower than
> > unwinding the stack with returns.
>
> But I could say the same thing about heap allocations vs. stack
> allocations. Yet those preaching "avoid exceptions" still, for the most
> part, use the heap with reckless abandon.
>
> > In particular, exceptions on such systems tend to be optimized for the
> > case that they are not thrown.
>
> So, in order to compare using exceptions with using return codes, one
> has to do a probabilistic analysis on how often the exception would be
> thrown in practice to infer which program would overall run faster.
> That, or write the program both ways and measure it.
>
> The tradeoff isn't just speed; it's about correctness and the ability to
> reason about the code. Using exceptions to avoid things like two phase
> construction are a definite win from a usability point of view.
>
> I'm not saying that there is never a time to avoid exceptions. But for
> the most part, if people aren't backing that avoidance with solid
> numbers or a complexity analysis, it is just another premature
> optimization.

Note that I did not support exception use or say avoid all exception
use anywhere in my post. Please do not attribute arguments to me which
I did not make. I was merely stating facts about the performance of
exceptions on current desktops and servers to correct misinformation
from Thomas Richter. He suggested that return codes and exception have
roughly the same work to do and should be about as fast. (As I
explained thoroughly, this is not true for common desktops and
servers, though perhaps it is true for machines which have actual
equal random access performance characteristics, perhaps something
embedded.)

As a matter of opinion, I very much like exceptions, and I still use
them in products I consider relatively performance critical (such as
my home-brewed GNU Make replacement) because it's so much easier to
write C++ code using them, and when properly done the performance hit
is rather small.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Andrew on 10 Mar 2010 10:52

> Making good design decisions about exception usage requires a
> balanced, rational appreciation of these trade offs IN THE CONTEXT OF
> THE SPECIFIC APPLICATION(S) AND DEVELOPMENT TEAM.

Indeed. For the environments and applications I typically work on, I
reckon it makes sense to use exceptions rather than error codes. But
several years back there was a SCADA app (SCADA == Supervisory Control
And Data Acquisition) I worked on where this would very probably be
the wrong thing to do, for performance reasons. Maybe the OP runs into
people that work in the performance-demanding environment of SCADA or
something similar.

Another environment where I have heard they don't like the overhead of
exceotions (even when they aren't thrown) is telecomms. If memory
serves, ACE which is sometimes used in telecoms, has or had a build
mode where you can turn exceptions off, for this reason.

Regards,

Andrew Marlow


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Joshua Maurice on 5 Apr 2010 09:18
On Apr 3, 1:33 pm, Mathias Gaunard <loufo...(a)gmail.com> wrote:
> On 2 avr, 23:04, "A. McKenney" <alan_mckenn...(a)yahoo.com> wrote:
>
> > One difference (correct me if I'm wrong!) is that
> > Jave _requires_ exception specifications, so
> > you can at least see from the function prototype
> > what exceptions you can get.
>
> It does, but you can bypass it by deriving your exception from a
> specific type, or from using the base type of all exceptions in the
> throws clause of the function declaration.
>
> > This makes it a
> > little more like error codes, in that there
> > is something in the function signature.
> > Unfortunately, this was not an option when
> > they put exceptions into C++ .
>
> Checked exceptions don't really work anyway. It's more of an annoyance
> than anything else.
> Consider a generic wrapper or container. It must throw whatever it is
> holding does.

Statically checked exceptions (as Java currently implements) are not
terribly useful, I agree.

However, let me take this opportunity to plug my own idea on checked
exceptions. Allow each function to have a statically_throws
declaration or no statically_throws declaration. A function without a
statically_throws declaration is a propagator; it acts as if it had a
statically_throws declaration exactly of what it actually throws. When
the compiler compiles down each function, it adds metadata to the
function of its source-code-declared statically_throws declaration (or
lack thereof) and what it actually throws. The compiler and linker can
then use this information to statically check source-code-declared
statically_throws declarations at link time (and some at compile
time).

For example, generic containers would be written without
statically_throws declarations. It would just propagate whatever
exceptions its contained elements can statically throw.

This idea is based on the observation that you mostly only want to
specify a statically checked throws declaration at "interfaces"
between "components". In the internals, it's irrelevant clutter, but
when you're using someone else's API, it matters, and when determining
the correctness of your own code and API, statically checked exception
throws declarations would be a great tool.

Unfortunately this idea is doomed for the same reason that extern
template is doomed: it would require linker support beyond the C
object model. Then there's also the problems of how this would
interact with dlls which I have not thought through, and which the C++
standard committee cannot ignore.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 | 
Pages: 1
Prev: Summary of C++0x Feature Availability
Next: Detecting a static member variable