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

[mike3]

Hi.

Is this a good idea?:

<begin code>
/* Addition operator: += */
const BigFix &BigFix::operat or+=(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_AddUnsign ed(this, &rhs)).dwErrCod e !=
XXXX_SUCCESS)
throw Exception(err); <<<<<<<<<<<<<<< <<< here

/* Set sign */
sign = lhs_sign;
}

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

if((lhs_sign == -1) && (rhs_sign == 1))
{
/* Subtract */
sign = 1;
if((err = MPFix_SubUnsign ed(this, &rhs)).dwErrCod e !=
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_AddUnsign ed(), MPFix_SubUnsign ed() 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_AddUnsign ed() and MPFix_SubUnsign ed() 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?

[James Kanze]

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: ja*********@gma il.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[mike3]

On May 26, 4:14 am, James Kanze <james.ka...@gm ail.comwrote:

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: james.ka...@gma il.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[mike3]

On May 26, 4:14 am, James Kanze <james.ka...@gm ail.comwrote:

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: james.ka...@gma il.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[peter koch]

On 26 Maj, 21:47, mike3 <mike4...@yahoo .comwrote:

On May 26, 4:14 am, James Kanze <james.ka...@gm ail.comwrote:

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

[James Kanze]

On May 26, 9:47 pm, mike3 <mike4...@yahoo .comwrote:

On May 26, 4:14 am, James Kanze <james.ka...@gm ail.comwrote:

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: ja*********@gma il.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]