Google Groups Home
Help | Sign in
consensus on exceptions?
There are currently too many topics in this group that display first. To make this topic appear first, remove this option from another topic.
There was an error processing your request. Please try again.
flag
  Messages 1 - 25 of 109 - Collapse all   Newer >
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
Gabriel Zachmann  
View profile
 More options Dec 11 2000, 2:20 pm
Newsgroups: comp.lang.c++.moderated
From: z...@igd.fhg.de (Gabriel Zachmann)
Date: 11 Dec 2000 14:19:48 -0500
Local: Mon, Dec 11 2000 2:19 pm
Subject: consensus on exceptions?

I am trying to decide whether or not to use exceptions.

I searched this NG with deja
and read some GotW (http://www.peerdirect.com/resources/)
and some C++ tips (http://cpptips.hyperformix.com/Exceptions.html);
in particular http://cpptips.hyperformix.com/cpptips/except_consensus
was very informative.

But I'm afraid I still don't see if there is a consensus
whether or not
                Exceptions are a Good Thing?

I found a lot of tips and discussion about the technicalities of
exceptions, but the big question is
 From what I read, there seems to be a consensus that:
1. Writing exception-safe code is harder than without exceptions;
2. Excpetions introduce a second path of control flow "behind the scenes",
   which increases the complexity of the code;
3. In order to do decent error-handling in constructors, you must use
   exceptions.

So, my questions are:
a) should I use exceptions only for constructors and error codes for
   all other methods?
b) if exceptions are used in general, should functions return *only*
   error codes *or* throw exceptions? (i.e., is it ok to mix both in one
   method?)
c) should exceptions be used only for "exceptional" cases, or could they
   also be used for not-so-exceptional things, like bogus parameters passed
   in from the caller?

All insights and pointers will be greatly appreciated.
TIA,
Gab.

--
/---------------------------------------------------------------------\
| Paradigm is a word too often used by those                          |
| who would like to have a new idea                                   |
| but cannot think of one.                                            |
|                     (Mervyn King, Deputy Governor, Bank of England) |
|                                                                     |
| z...@igd.fhg.de          g...@gab.cx        Gabriel.Zachm...@gmx.net |
| www.igd.fhg.de/~zach/    www.gab.cx        __@/'                    |
\---------------------------------------------------------------------/

      [ Send an empty e-mail to c++-h...@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Andy Watson  
View profile
 More options Dec 11 2000, 5:37 pm
Newsgroups: comp.lang.c++.moderated
From: Andy Watson <AWat...@ATTGlobal.Net>
Date: 11 Dec 2000 17:37:57 -0500
Local: Mon, Dec 11 2000 5:37 pm
Subject: Re: consensus on exceptions?
To be honest I don't usually use them when coding.  99% of the time
one can write code that handles error coditions gracefully  (how we
used to do it in the old days)..

However, I have found that many poorly designed class libraries use
them a lot.  In this situation one has to catch the exceptions thrown
- MFC is a classic example of this..

The only case where they are indeed usefull is to prevent a critical
exception that may force program termination..  In this case its often
usefull to wrap the code with an exception then call your error handle
to notify the user and roll back to a stable state.

Andy

On 11 Dec 2000 14:19:48 -0500, z...@igd.fhg.de (Gabriel Zachmann)
wrote:

      [ Send an empty e-mail to c++-h...@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Chris Uzdavinis  
View profile
 More options Dec 11 2000, 5:42 pm
Newsgroups: comp.lang.c++.moderated
From: Chris Uzdavinis <ch...@atdesk.com>
Date: 11 Dec 2000 17:42:14 -0500
Local: Mon, Dec 11 2000 5:42 pm
Subject: Re: consensus on exceptions?

z...@igd.fhg.de (Gabriel Zachmann) writes:
> 1. Writing exception-safe code is harder than without exceptions;

True.  However, whether you like it or not, exceptions are in the
language and the WILL happen.  The question is, will your code work
when they do happen?

> 2. Excpetions introduce a second path of control flow "behind the scenes",
>    which increases the complexity of the code;

This path of control exiting "anywhere" already exists.  Ignoring it
does not make it go away.

> 3. In order to do decent error-handling in constructors, you must use
>    exceptions.

Yes, there is no other good way to indicate failure.  Or, alternately,
design objects such that construction CAN'T fail.  Then you don't have
to throw exceptions.

> So, my questions are:
> a) should I use exceptions only for constructors and error codes for
>    all other methods?

Well, any exceptional situation where you know THAT an error occurred
but you don't know HOW to handle it is a good candidate for
exceptions.

I rarely throw them myself, but I try to write code that works if they
do happen to get thrown.  This is because my code is a middleware
library, with user code calling into me, and I call back out into
them through callbacks.  So they can throw exceptions and my code
really needs to continue working.

> b) if exceptions are used in general, should functions return *only*
>    error codes *or* throw exceptions? (i.e., is it ok to mix both in one
>    method?)

It's ok to mix, but have a consistent strategy.  If your functions are
internal to a subsystem, it doesn't matter how they INTERNALLY handle
errors, and error codes are fine.  (Your code knows about your other
code.)  Exceptions are generally better for cross-subsystem kinds of
operations, where it is someone else's code that has to handle an
error you detect.  Or, if your code is seperated enough to where you
don't want part of your code to know about error codes of another part
of your application.

> c) should exceptions be used only for "exceptional" cases, or could they
>    also be used for not-so-exceptional things, like bogus parameters passed
>    in from the caller?

Never use them for not-so-exceptional things that can be handled
better in other ways.  Bogus parameters can indeed be VERY
exceptional, it all depends on the application.  

I throw an exception when I know that I've detected misuse of some
code, especially if a user is doing it.  If it's my own code misusing
other parts of my code, then it's simply a bug and the assert macro is
better at finding that.

--
Chris

      [ Send an empty e-mail to c++-h...@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Alan Griffiths  
View profile
 More options Dec 12 2000, 7:39 am
Newsgroups: comp.lang.c++.moderated
From: Alan Griffiths <alan.griffi...@uk.experian.com>
Date: 12 Dec 2000 07:40:26 -0500
Local: Tues, Dec 12 2000 7:40 am
Subject: Re: consensus on exceptions?
In article <slrn93a6ke.5e1p.z...@schwind.igd.fhg.de>,

  z...@igd.fhg.de wrote:

> I am trying to decide whether or not to use exceptions.

> I searched this NG with deja
> and read some GotW (http://www.peerdirect.com/resources/)
> and some C++ tips (http://cpptips.hyperformix.com/Exceptions.html);
> in particular http://cpptips.hyperformix.com/cpptips/except_consensus
> was very informative.

    http://people.ne.mediaone.net/abrahams/abrahams.html
    http://www.octopull.demon.co.uk/c++/dragons/

> But I'm afraid I still don't see if there is a consensus
> whether or not
>                 Exceptions are a Good Thing?

> I found a lot of tips and discussion about the technicalities of
> exceptions, but the big question is
>  From what I read, there seems to be a consensus that:
> 1. Writing exception-safe code is harder than without exceptions;

False.  Writing exception safe code is easier than equivalent code
written using return codes and conditional branches (and setjmp &
longjmp).

What is true is that it requires a different coding style that many
developers are unaware of.

> 2. Excpetions introduce a second path of control flow "behind the

scenes",

One needs to think about program state not control paths.  For example,
on exit from a function (either by return or exception) the destructors
of all auto variables will have been executed.

>    which increases the complexity of the code;

When using error returns the need for multiple test & branches
introduces the same number of alternative paths.  But they need to be
managed manually - which increases code complexity.

> 3. In order to do decent error-handling in constructors, you must use
>    exceptions.

False.  In the 1980's exceptions were not in the language and idioms
were developed to accomplish this.  In particular "Two Phase
Construction" - the constructor didn't do anything that could fail, and
the client code was required to call an "init()" member function before
using the object.

Avoiding exceptions increases the complexity of both implementation and
client code - but does allow "decent error-handling".

> So, my questions are:
> a) should I use exceptions only for constructors and error codes for
>    all other methods?

No, use exceptions for operations that:

  /1/ may fail but are expected to work (e.g. allocating resources) and
  /2/ are distant from "domain" code that reacts to the failure.

> b) if exceptions are used in general, should functions return *only*
>    error codes *or* throw exceptions? (i.e., is it ok to mix both in
one
>    method?)

It is OK to mix them.

> c) should exceptions be used only for "exceptional" cases, or could
they
>    also be used for not-so-exceptional things, like bogus parameters
passed
>    in from the caller?

This is an edge case:

  /1/ Do you want to document and test that exceptions are thrown
      for "bogus parameters"?

  /2/ Do you want to specify valid parameters and leave the rest as
      "undefined behaviour"?

Both are valid approaches depending on your context.

> All insights and pointers will be greatly appreciated.

HTH
--
Alan Griffiths                        http://www.octopull.demon.co.uk/
Senior Systems Consultant, Experian   tel: +44 115 968 5118
Chair, Association of C and C++ Users http://accu.org/

Sent via Deja.com http://www.deja.com/
Before you buy.

      [ Send an empty e-mail to c++-h...@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
James Kanze  
View profile
 More options Dec 12 2000, 7:47 am
Newsgroups: comp.lang.c++.moderated
From: James Kanze <James.Ka...@dresdner-bank.com>
Date: 12 Dec 2000 07:47:51 -0500
Local: Tues, Dec 12 2000 7:47 am
Subject: Re: consensus on exceptions?

Gabriel Zachmann wrote:
> I am trying to decide whether or not to use exceptions.
> I searched this NG with deja
> and read some GotW (http://www.peerdirect.com/resources/)
> and some C++ tips (http://cpptips.hyperformix.com/Exceptions.html);
> in particular http://cpptips.hyperformix.com/cpptips/except_consensus
> was very informative.
> But I'm afraid I still don't see if there is a consensus
> whether or not
>                 Exceptions are a Good Thing?

There is no concensus.  Some people swear by them.  Others swear at
them.

> I found a lot of tips and discussion about the technicalities of
> exceptions, but the big question is
>  From what I read, there seems to be a consensus that:
> 1. Writing exception-safe code is harder than without exceptions;
> 2. Excpetions introduce a second path of control flow "behind the scenes",
>    which increases the complexity of the code;
> 3. In order to do decent error-handling in constructors, you must use
>    exceptions.

Add overloaded operators to 3, and you've summarized it pretty well.
On the other hand, it's possible to design constructors so they don't
fail, or so that you can check them afterwards (a la iostream), so
it's not necessarily as big a point as is sometimes pretended.

And you missed:

4. Exceptions make the main body of the function simpler, so easier to
   write and to understand.

I don't think there is one true answer.  Generally, I'm fairly
sceptical of exceptions, but then, I'm sceptical of unproven solutions
in general.  *IF* you have a lot of cases where error detection is at
a much lower level than error handling, exceptions can simplify the
intermediate code significantly.  On the other hand, they do create a
whole new family of problems involving exception safety, and the make
rigorous analysis of code flow more difficult.  Which aspect weighs
heaviest will vary according to the application and the organization.

Globally, I'd say that exceptions should not be used in a critical
application, where human life is at stake.  And of course, in a lot of
simple applications (compilers, etc.), they're really irrelevant -- in
exceptional cases, you just abort with an error message.  For typical
server applications, etc., however, they might have a place to abort
an operation without killing the process.

> So, my questions are:
> a) should I use exceptions only for constructors and error codes for
>    all other methods?

No.  Be consistent.

> b) if exceptions are used in general, should functions return *only*
>    error codes *or* throw exceptions? (i.e., is it ok to mix both in one
>    method?)

Ditto.

> c) should exceptions be used only for "exceptional" cases, or could they
>    also be used for not-so-exceptional things, like bogus parameters passed
>    in from the caller?

I would hope that a bogus parameter is something really exceptional,
if it comes from within my program.  I wouldn't use exceptions for
errors in user input, however.

--
James Kanze                               mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

      [ Send an empty e-mail to c++-h...@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Alf P. Steinbach  
View profile
 More options Dec 12 2000, 9:03 am
Newsgroups: comp.lang.c++.moderated
From: "Alf P. Steinbach" <alf_steinb...@my-deja.com>
Date: 12 Dec 2000 09:04:31 -0500
Local: Tues, Dec 12 2000 9:04 am
Subject: Re: consensus on exceptions?
In article <slrn93a6ke.5e1p.z...@schwind.igd.fhg.de>,

  z...@igd.fhg.de wrote:

> I am trying to decide whether or not to use exceptions.

The only consensus of interest is then, IMO, the consensus of those
who'll maintain the code.

>...
> But I'm afraid I still don't see if there is a consensus
> whether or not
>                 Exceptions are a Good Thing?

Always depends on the application of the tool.  Icepicks can
be great, although not a Good Thing as murder weapons.  Of
course you mean as an error reporting mechanism, but even in
that context there's room for application and misapplication.

>...
>  From what I read, there seems to be a consensus that:
> 1. Writing exception-safe code is harder than without exceptions;

Meaningless or false.

(1) If there can be no exceptions, then the code is exception-safe.

(2) Otherwise, you *need* exception handling in order to make the
    code exception safe.

(3) With a more general interpretation, writing "error safe" code
    is distinctly easier using exception handling (that's the
    whole point of the mechanism).

> 2. Excpetions introduce a second path of control flow "behind the

     scenes", which increases the complexity of the code;

First part is true, conclusion is generally false.  Generally the
complexity of the code is lowered because you can separate error
handling from normal case code, and because you don't have to
clutter the code with return value checking.  Otoh. it's *possible*
to increase the actual complexity of the code by lowering the
apparent complexity, e.g. code that is structured to function
correctly in the presence of exceptions but only because things
get done in a certain order, and where this isn't documented.

> 3. In order to do decent error-handling in constructors, you must
>    use exceptions.

Generally this is false, but exceptions are way more convenient
for this than other means (e.g. two-phase construction with Init
method, reference error parameter or ditto global, error handling
function, whatever).  What you do gain is automatic deallocation,
plus -- depending on the alternative considered -- removal of the
possibility of using a non-properly constructed object.  These
advantages are so great that you'd need a very good reason *not*
to use exceptions for error reporting from constructors (one such
reason being the deallocation bug of Visual C++ 5.0 and earlier).

> ...
> a) should I use exceptions only for constructors and error codes for
>    all other methods?

No.  But that doesn't imply the opposite, that you should always use
exceptions.  Use sound judgement, considering always how your classes
will or may be used.  This call can be tough, since there is a
"conflict of interest" present.  At the lowest levels of the code
where failures often occur, efficiency dictates return codes or some
such scheme, while correctness guarantees dictates using exceptions
(essentially this boils down to the guarantees you endowe your
methods with; one solution is to have one set of "bare" error-code
based functions and one set of "safe" exception-throwing wrappers).

> b) if exceptions are used in general, should functions return *only*
>    error codes *or* throw exceptions? (i.e., is it ok to mix both in
>    one method?)

Don't mix error reporting strategies.  But you can use return codes
for success reporting.  Again, this boils down to the contracts you
define for the methods, and designing those contracts can be hard.

> c) should exceptions be used only for "exceptional" cases, or could
>    they  also be used for not-so-exceptional things, like bogus
>    parameters passed in from the caller?

First is easy: yes.  Second part is false: bogus parameters *are* (or
at least, should be) exceptional.  I'd use exceptions for that.

Hth.,

- Alf

--
alf_DOT_steinbach_AT_ac_DOT_com (clean the address before replying)

Sent via Deja.com http://www.deja.com/
Before you buy.

      [ Send an empty e-mail to c++-h...@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Robert J. Hansen  
View profile
 More options Dec 12 2000, 9:04 am
Newsgroups: comp.lang.c++.moderated
From: "Robert J. Hansen" <rjhan...@inav.net>
Date: 12 Dec 2000 09:05:19 -0500
Local: Tues, Dec 12 2000 9:05 am
Subject: Re: consensus on exceptions?

> I am trying to decide whether or not to use exceptions.

Don't think of exceptions as being error handling constructs; think of them
as program flow constructs.  Just like a goto isn't automatically harmful or
beneficial in C, using exceptions isn't automatically good one way or
another in C++.

> 1. Writing exception-safe code is harder than without exceptions;

Untrue.  Writing exceptionless code requires that you introduce
functionality to handle exceptional states.  One way or another, exception
conditions occur and you'd better be equipped to handle them.  If you don't
like how new throws an exception on a bad memory allocation, you're free to
use new(nothrow), but you'd better check for NULL after every allocation.

See what I mean?  One way or another, error conditions must be checked for.
Exceptions are oftentimes an elegant way to check for, and handle, these
error states.

> 2. Excpetions introduce a second path of control flow "behind the scenes",
>    which increases the complexity of the code;

No.  They change a second path of control flow, not add a new one.  The
original second path starts at an error state and leads straight to a
coredump.  With error handling (which may include exceptions as part of an
intelligent error design), this catastrophic execution path can be
redirected to a more graceful exit, or even have termination avoided
altogether.

> 3. In order to do decent error-handling in constructors, you must use
>    exceptions.

Not necessarily.  Consider:

class A
{
   public:
      int errorstate;
      A(void)
         {
            errorstate = 0;
            // do more stuff here, traps an error
            errorstate = 1; return;
            // do more stuff here if no error trapped
         }

};

int main(int argc, char *argv[])
{
   A myfunc;
   if (myfunc.errorstate) { // do error handling stuff here

}

Note that I don't recommend doing things this way.  But it does show that
it's possible to do error handling in constructors without exceptions (even
if it means just flagging a failure appropriately).

> a) should I use exceptions only for constructors and error codes for
>    all other methods?

Use them whenever they're appropriate.  How will you know if they're
appropriate?  By using your experience.  So get out and experiment around
with exceptions some.  :)

> b) if exceptions are used in general, should functions return *only*
>    error codes *or* throw exceptions? (i.e., is it ok to mix both in one
>    method?)

Just be consistent.  If you do one, then only do that one.  If you do both,
then always do both.  Etc.

> c) should exceptions be used only for "exceptional" cases, or could they
>    also be used for not-so-exceptional things, like bogus parameters
passed
>    in from the caller?

Exceptions are not only useful for errors.  Consider:

if (...)
   {
      if (...)
         {
            if (...)
               {
                  if (...) throw myException();
// insert multiple closing brackets here

catch (myException &e)
{
.... etc.

}

.... In that above case, exceptions work as a better GOTO.  Remember:
exceptions /are just program control statements/.  They aren't magically
tied to error conditions.

      [ Send an empty e-mail to c++-h...@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Adrian Edmonds  
View profile
 More options Dec 12 2000, 11:53 am
Newsgroups: comp.lang.c++.moderated
From: "Adrian Edmonds" <adr...@sentry-com.co.il>
Date: 12 Dec 2000 11:51:57 -0500
Local: Tues, Dec 12 2000 11:51 am
Subject: Re: consensus on exceptions?

"Gabriel Zachmann" <z...@igd.fhg.de> wrote in message

news:slrn93a6ke.5e1p.zach@schwind.igd.fhg.de...

<snip>
> So, my questions are:
> a) should I use exceptions only for constructors and error codes for
>    all other methods?
> b) if exceptions are used in general, should functions return *only*
>    error codes *or* throw exceptions? (i.e., is it ok to mix both in one
>    method?)
> c) should exceptions be used only for "exceptional" cases, or could they
>    also be used for not-so-exceptional things, like bogus parameters
passed
>    in from the caller?

IMHO

a) no
b) no. Use error codes for run of the mill errors and exceptions for
catastrophic failures
c) I agree with the first part

Adrian

P.S Your sig is too long.

      [ Send an empty e-mail to c++-h...@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]


    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
James Kanze  
View profile
 More options Dec 12 2000, 11:54 am
Newsgroups: comp.lang.c++.moderated
From: James Kanze <James.Ka...@dresdner-bank.com>
Date: 12 Dec 2000 11:52:33 -0500
Local: Tues, Dec 12 2000 11:52 am
Subject: Re: consensus on exceptions?

Chris Uzdavinis wrote:
> z...@igd.fhg.de (Gabriel Zachmann) writes:
> > 1. Writing exception-safe code is harder than without exceptions;
> True.  However, whether you like it or not, exceptions are in the
> language and the WILL happen.  The question is, will your code work
> when they do happen?

That's not really true.  The language supports exceptions, but it
certainly doesn't require their use.  The standard library only throws
exceptions in a few specific cases, which it is possible to avoid.

> > 2. Excpetions introduce a second path of control flow "behind the scenes",
> >    which increases the complexity of the code;
> This path of control exiting "anywhere" already exists.  Ignoring it
> does not make it go away.

It doesn't exist in most of the code I write.

> > 3. In order to do decent error-handling in constructors, you must use
> >    exceptions.
> Yes, there is no other good way to indicate failure.  Or,
> alternately, design objects such that construction CAN'T fail.  Then
> you don't have to throw exceptions.

Designing constructors so they can't fail is often a good idea anyway.

> > So, my questions are:
> > a) should I use exceptions only for constructors and error codes for
> >    all other methods?
> Well, any exceptional situation where you know THAT an error occurred
> but you don't know HOW to handle it is a good candidate for
> exceptions.
> I rarely throw them myself, b