Is this a good idea? (Error handling with overloaded operators)

Discussion in 'C++' started by mike3, May 26, 2007.

  1. mike3

    mike3 Guest

    Hi.

    Is this a good idea?:

    <begin code>
    /* Addition operator: += */
    const BigFix &BigFix::eek:perator+=(const BigFix &rhs)
    {
    ErrorType err;
    int lhs_sign = sign, rhs_sign = rhs.sign;

    /* Special cases */
    if(lhs_sign == 0) /* interpreted as zero */
    {
    /* treat as zero */
    return(rhs);
    }

    if(rhs_sign == 0) /* interpreted as zero */
    {
    /* treat as zero */
    return(*this);
    }

    /* Compare signs */
    if(lhs_sign == rhs_sign)
    {
    /* Just do ordinary addition */
    if((err = MPFix_AddUnsigned(this, &rhs)).dwErrCode !=
    XXXX_SUCCESS)
    throw Exception(err); <<<<<<<<<<<<<<<<<< here

    /* Set sign */
    sign = lhs_sign;
    }

    if((lhs_sign == 1) && (rhs_sign == -1))
    {
    /* Subtract */
    if((err = MPFix_SubUnsigned(this, &rhs)).dwErrCode !=
    XXXX_SUCCESS)
    throw Exception(err); <<<<<<<<<<<<<<<<<< here
    }

    if((lhs_sign == -1) && (rhs_sign == 1))
    {
    /* Subtract */
    sign = 1;
    if((err = MPFix_SubUnsigned(this, &rhs)).dwErrCode !=
    XXXX_SUCCESS)
    throw Exception(err); <<<<<<<<<<<<<<<<<< here

    /* Reverse sign (we subtracted |this| - |rhs|, we want |rhs| - |
    this|) */
    sign = -sign;
    }

    /* Done! */
    return(*this);
    }
    <end code>

    What does that do, you might ask? Well, it's for a bignum library I've
    been making for a program that needs it, and it's supposed to overload
    the "+=" operator to add the big numbers, in this case big fixed-point
    numbers. I left out a few things like the definition of ErrorType and
    MPFix_AddUnsigned(), MPFix_SubUnsigned() for brevity but they are not
    what I am asking about here. You should be able to get the gist of
    what the code is supposed to do, just remember that
    MPFix_AddUnsigned() and MPFix_SubUnsigned() are just add/sub routines
    that treat both operands as positive.

    Anyway, with the explanation out of the way, I'd like some criticism
    of this, especially of the whole error handling. Is it really a good
    idea to just throw exceptions like that out of the operator on an
    overflow? Or would it be better to instead have some sort of "error
    flag" in the BigFix that is usually zero, but then is set to some
    nonzero number when an error occurs, depending on the error? The
    problem is that we have to catch exceptions from _every_ piece of
    code that uses the numbers. Unfortunately (or fortunately?) these seem
    to be the only two ways of getting error information outside of an
    overloaded operator like that (since it's meant to be used in
    expressions like "a += b" then it must return a _BigFix_ and not
    something else). So is this a good idea or a bad one?
     
    mike3, May 26, 2007
    #1
    1. Advertising

  2. mike3

    James Kanze Guest

    mike3 wrote:
    > Is this a good idea?:


    > Anyway, with the explanation out of the way, I'd like some criticism
    > of this, especially of the whole error handling. Is it really a good
    > idea to just throw exceptions like that out of the operator on an
    > overflow? Or would it be better to instead have some sort of "error
    > flag" in the BigFix that is usually zero, but then is set to some
    > nonzero number when an error occurs, depending on the error?


    It depends on the intended use. If the goal is behave as do the
    built-in types, then aborting is probably the best solution; the
    user should check his values up front. In many cases, however,
    this is a bit brutal, and exceptions are a good compromise.
    (Overflow will usually occur because the program didn't---or
    couldn't---correctly check its input, not because program state
    has been corrupted.) A flag or a special value which propagates
    emulates IEEE behavior, of course, which has also proven itself
    in practice. It does mean that you have to define behavior for
    all such cases (but you can inspire yourself from the IEEE
    specification).

    > The problem is that we have to catch exceptions from _every_
    > piece of code that uses the numbers.


    If you don't catch it, you abort. Depending on use, that might
    be correct.

    --
    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, May 26, 2007
    #2
    1. Advertising

  3. mike3

    mike3 Guest

    On May 26, 4:14 am, James Kanze <> wrote:
    > mike3 wrote:
    > > Is this a good idea?:
    > > Anyway, with the explanation out of the way, I'd like some criticism
    > > of this, especially of the whole error handling. Is it really a good
    > > idea to just throw exceptions like that out of the operator on an
    > > overflow? Or would it be better to instead have some sort of "error
    > > flag" in the BigFix that is usually zero, but then is set to some
    > > nonzero number when an error occurs, depending on the error?

    >
    > It depends on the intended use. If the goal is behave as do the
    > built-in types, then aborting is probably the best solution; the
    > user should check his values up front. In many cases, however,
    > this is a bit brutal, and exceptions are a good compromise.
    > (Overflow will usually occur because the program didn't---or
    > couldn't---correctly check its input, not because program state
    > has been corrupted.) A flag or a special value which propagates
    > emulates IEEE behavior, of course, which has also proven itself
    > in practice. It does mean that you have to define behavior for
    > all such cases (but you can inspire yourself from the IEEE
    > specification).
    >
    > > The problem is that we have to catch exceptions from _every_
    > > piece of code that uses the numbers.

    >
    > If you don't catch it, you abort. Depending on use, that might
    > be correct.
    >


    However what if I don't want it to just abort because I neglected
    to handle some exception in some loop or something that involves
    use of the big number operations?

    > --
    > 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
     
    mike3, May 26, 2007
    #3
  4. mike3

    mike3 Guest

    On May 26, 4:14 am, James Kanze <> wrote:
    > mike3 wrote:
    > > Is this a good idea?:
    > > Anyway, with the explanation out of the way, I'd like some criticism
    > > of this, especially of the whole error handling. Is it really a good
    > > idea to just throw exceptions like that out of the operator on an
    > > overflow? Or would it be better to instead have some sort of "error
    > > flag" in the BigFix that is usually zero, but then is set to some
    > > nonzero number when an error occurs, depending on the error?

    >
    > It depends on the intended use. If the goal is behave as do the
    > built-in types, then aborting is probably the best solution; the
    > user should check his values up front. In many cases, however,
    > this is a bit brutal, and exceptions are a good compromise.
    > (Overflow will usually occur because the program didn't---or
    > couldn't---correctly check its input, not because program state
    > has been corrupted.) A flag or a special value which propagates
    > emulates IEEE behavior, of course, which has also proven itself
    > in practice. It does mean that you have to define behavior for
    > all such cases (but you can inspire yourself from the IEEE
    > specification).
    >
    > > The problem is that we have to catch exceptions from _every_
    > > piece of code that uses the numbers.

    >
    > If you don't catch it, you abort. Depending on use, that might
    > be correct.
    >


    However what if I don't want it to just abort because I neglected
    to handle some exception in some loop or something that involves
    use of the big number operations?

    > --
    > 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
     
    mike3, May 26, 2007
    #4
  5. mike3

    peter koch Guest

    On 26 Maj, 21:47, mike3 <> wrote:
    > On May 26, 4:14 am, James Kanze <> wrote:
    >
    >
    >
    >
    >
    > > mike3 wrote:
    > > > Is this a good idea?:
    > > > Anyway, with the explanation out of the way, I'd like some criticism
    > > > of this, especially of the whole error handling. Is it really a good
    > > > idea to just throw exceptions like that out of the operator on an
    > > > overflow? Or would it be better to instead have some sort of "error
    > > > flag" in the BigFix that is usually zero, but then is set to some
    > > > nonzero number when an error occurs, depending on the error?

    >
    > > It depends on the intended use. If the goal is behave as do the
    > > built-in types, then aborting is probably the best solution; the
    > > user should check his values up front. In many cases, however,
    > > this is a bit brutal, and exceptions are a good compromise.
    > > (Overflow will usually occur because the program didn't---or
    > > couldn't---correctly check its input, not because program state
    > > has been corrupted.) A flag or a special value which propagates
    > > emulates IEEE behavior, of course, which has also proven itself
    > > in practice. It does mean that you have to define behavior for
    > > all such cases (but you can inspire yourself from the IEEE
    > > specification).

    >
    > > > The problem is that we have to catch exceptions from _every_
    > > > piece of code that uses the numbers.


    No you don't: you catch the exception everywhere you want to handle
    the error, and that is far rarer than every time you use your bignum.

    >
    > > If you don't catch it, you abort. Depending on use, that might
    > > be correct.

    >
    > However what if I don't want it to just abort because I neglected
    > to handle some exception in some loop or something that involves
    > use of the big number operations?


    What is the alternative? I hope you don't want to just compute along
    with bad data. The simple truth is that if there is an error, the best
    way to handle it is to react to it. Ignoring it is not really an
    option. Using exceptions requires you to do an active effort to
    neglect it.
    As James pointed out, using the IEEE specification could be a good
    inspiration. One thing you could reasonably do is to specify the
    action to take in case of an overflow. One reasonable approach could
    be to return bigint_max or something like that, and if you specifiy
    this overflow is no longer an error.

    /Peter
     
    peter koch, May 26, 2007
    #5
  6. mike3

    James Kanze Guest

    On May 26, 9:47 pm, mike3 <> wrote:
    > On May 26, 4:14 am, James Kanze <> wrote:
    > > mike3 wrote:
    > > > Is this a good idea?:
    > > > Anyway, with the explanation out of the way, I'd like some criticism
    > > > of this, especially of the whole error handling. Is it really a good
    > > > idea to just throw exceptions like that out of the operator on an
    > > > overflow? Or would it be better to instead have some sort of "error
    > > > flag" in the BigFix that is usually zero, but then is set to some
    > > > nonzero number when an error occurs, depending on the error?


    > > It depends on the intended use. If the goal is behave as do the
    > > built-in types, then aborting is probably the best solution; the
    > > user should check his values up front. In many cases, however,
    > > this is a bit brutal, and exceptions are a good compromise.
    > > (Overflow will usually occur because the program didn't---or
    > > couldn't---correctly check its input, not because program state
    > > has been corrupted.) A flag or a special value which propagates
    > > emulates IEEE behavior, of course, which has also proven itself
    > > in practice. It does mean that you have to define behavior for
    > > all such cases (but you can inspire yourself from the IEEE
    > > specification).


    > > > The problem is that we have to catch exceptions from _every_
    > > > piece of code that uses the numbers.


    > > If you don't catch it, you abort. Depending on use, that might
    > > be correct.


    > However what if I don't want it to just abort because I neglected
    > to handle some exception in some loop or something that involves
    > use of the big number operations?


    Then catch the exception or use some other technique. As I
    said, IEEE has had some success with using special values which
    propagate.

    --
    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, May 27, 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. -Steve-
    Replies:
    2
    Views:
    377
    - Steve -
    Jul 28, 2003
  2. John Harrison
    Replies:
    5
    Views:
    332
    - Steve -
    Jul 29, 2003
  3. Andy Jarrell

    Inheriting overloaded operators

    Andy Jarrell, Nov 13, 2003, in forum: C++
    Replies:
    5
    Views:
    447
    Victor Bazarov
    Nov 13, 2003
  4. Pete Wilson
    Replies:
    1
    Views:
    322
    Mike Wahler
    Apr 3, 2004
  5. Replies:
    10
    Views:
    1,255
    Big K
    Feb 2, 2005
Loading...

Share This Page