returned error code

Discussion in 'C++' started by iu2, Jul 2, 2007.

  1. iu2

    iu2 Guest

    Hi all,
    I'm interested in your experience with returned error codes:
    What's better, return true/false for success/fail, or return 0 for Ok
    and a negative for failure?
    This question arose since in my project we use both systems, which led
    to a bug of misinterpreting returned code (a function retured 0 for
    success but the programmer treated it as false).

    The 0/negative system has been suggested to allow a range of failure
    codes. But practically we almost don't analyze them. Feeling that I
    shoud be thankful for handling and reporting error at all, I thought
    of getting rid of 0/negative system and work only with true/false.
    This also produces shorter code:
    "if (SomeFunc())" instead of "if (SomFunc() == 0)" (or even worse,
    due to tidy programming
    "if (SomeFunc() == code_ok)").

    What do you say?
    Thanks
    iu2, Jul 2, 2007
    #1
    1. Advertising

  2. iu2

    FabioAng Guest

    "iu2" <> wrote in message
    news:...
    > Hi all,
    > I'm interested in your experience with returned error codes:
    > ..., or return 0 for Ok and a negative for failure?


    That's the Unix sytle and I think it's a valid one.

    > This question arose since in my project we use both systems, which led
    > to a bug of misinterpreting returned code (a function retured 0 for
    > success but the programmer treated it as false).
    >
    > The 0/negative system has been suggested to allow a range of failure
    > codes. But practically we almost don't analyze them. Feeling that I
    > shoud be thankful for handling and reporting error at all, I thought
    > of getting rid of 0/negative system and work only with true/false.


    Why don't you want to use exceptions ?
    http://www.boost.org/more/generic_exception_safety.html

    Fabio
    FabioAng, Jul 2, 2007
    #2
    1. Advertising

  3. iu2

    James Kanze Guest

    On Jul 2, 9:51 am, iu2 <> wrote:

    > I'm interested in your experience with returned error codes:
    > What's better, return true/false for success/fail, or return 0 for Ok
    > and a negative for failure?


    Neither. You really need to use an enum:

    enum ErrorStatus
    {
    ok,
    someError,
    someOtherError
    } ;

    > This question arose since in my project we use both systems, which led
    > to a bug of misinterpreting returned code (a function retured 0 for
    > success but the programmer treated it as false).


    Precisely. The same problem exists for true/false: does true
    mean success, or failure. If you have to compare with a
    symbolic constant, like ok, the problem can't occur.

    > The 0/negative system has been suggested to allow a range of failure
    > codes. But practically we almost don't analyze them. Feeling that I
    > shoud be thankful for handling and reporting error at all, I thought
    > of getting rid of 0/negative system and work only with true/false.
    > This also produces shorter code:
    > "if (SomeFunc())" instead of "if (SomFunc() == 0)" (or even worse,
    > due to tidy programming
    > "if (SomeFunc() == code_ok)").


    Shorter doesn't always mean more readable or more
    understandable. This is one case where longer is better.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Jul 2, 2007
    #3
  4. iu2

    iu2 Guest

    On Jul 2, 10:13 am, "FabioAng" <> wrote:
    > "iu2" <> wrote in message
    >
    > news:...
    >
    > > Hi all,
    > > I'm interested in your experience with returned error codes:
    > > ..., or return 0 for Ok and a negative for failure?

    >
    > That's the Unix sytle and I think it's a valid one.
    >
    > > This question arose since in my project we use both systems, which led
    > > to a bug of misinterpreting returned code (a function retured 0 for
    > > success but the programmer treated it as false).

    >
    > > The 0/negative system has been suggested to allow a range of failure
    > > codes. But practically we almost don't analyze them. Feeling that I
    > > shoud be thankful for handling and reporting error at all, I thought
    > > of getting rid of 0/negative system and work only with true/false.

    >
    > Why don't you want to use exceptions ?http://www.boost.org/more/generic_exception_safety.html
    >
    > Fabio


    I'd like to but:
    1. It's too late for my project now...
    2. In some cases I don't want an exception. For example something
    fails, but I want to respond only after x successive failures. Then
    each single failure should realy return an error code (I think) and
    somewhere higher in the calling path I count the failures.

    iu2
    iu2, Jul 2, 2007
    #4
  5. On Mon, 02 Jul 2007 02:41:45 -0700, James Kanze wrote:
    >On Jul 2, 9:51 am, iu2 <> wrote:
    >> I'm interested in your experience with returned error codes:
    >> What's better, return true/false for success/fail, or return 0 for Ok
    >> and a negative for failure?
    >> This question arose since in my project we use both systems, which led
    >> to a bug of misinterpreting returned code (a function retured 0 for
    >> success but the programmer treated it as false).

    >
    >Precisely. The same problem exists for true/false: does true
    >mean success, or failure. If you have to compare with a
    >symbolic constant, like ok, the problem can't occur.


    Naming conventions are helpful in such cases. Functions that start
    with is... or has... are supposed to answer a question, e.g.

    bool isConnected (DBConnection& dbc);


    --
    Roland Pibinger
    "The best software is simple, elegant, and full of drama" - Grady Booch
    Roland Pibinger, Jul 2, 2007
    #5
  6. iu2

    James Kanze Guest

    On Jul 2, 2:45 pm, (Roland Pibinger) wrote:
    > On Mon, 02 Jul 2007 02:41:45 -0700, James Kanze wrote:
    > >On Jul 2, 9:51 am, iu2 <> wrote:
    > >> I'm interested in your experience with returned error codes:
    > >> What's better, return true/false for success/fail, or return 0 for Ok
    > >> and a negative for failure?
    > >> This question arose since in my project we use both systems, which led
    > >> to a bug of misinterpreting returned code (a function retured 0 for
    > >> success but the programmer treated it as false).


    > >Precisely. The same problem exists for true/false: does true
    > >mean success, or failure. If you have to compare with a
    > >symbolic constant, like ok, the problem can't occur.


    > Naming conventions are helpful in such cases. Functions that start
    > with is... or has... are supposed to answer a question, e.g.


    > bool isConnected (DBConnection& dbc);


    That's a different issue. I wouldn't say that a function like
    "isConnected" failed. It returns status information. (Almost
    by definition, a function whose name starts with "is" returns a
    bool.) On the other hand, if the function name is
    "isConnected", it should almost certainly be const, and not try
    to establish a connection (which might fail). And the meaning
    of a bool return value of a function named "establishConnection"
    is ambiguous.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Jul 3, 2007
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Wes Stebbins
    Replies:
    1
    Views:
    5,752
  2. obeOnline
    Replies:
    2
    Views:
    20,473
    obeOnline
    Jan 27, 2005
  3. Replies:
    2
    Views:
    11,439
    ed suslen
    Sep 27, 2005
  4. Mukesh
    Replies:
    4
    Views:
    697
    Steven Cheng[MSFT]
    Dec 25, 2006
  5. Justin Ezequiel
    Replies:
    4
    Views:
    55
    Gregory Ewing
    Apr 26, 2014
Loading...

Share This Page