Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Is this a good idea? (Error handling with overloaded operators)

Reply
Thread Tools

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

 
 
mike3
Guest
Posts: n/a
 
      05-25-2007
Hi.

Is this a good idea?:

<begin code>
/* Addition operator: += */
const BigFix &BigFix: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?

 
Reply With Quote
 
 
 
 
James Kanze
Guest
Posts: n/a
 
      05-26-2007
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: http://www.velocityreviews.com/forums/(E-Mail Removed)
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

 
Reply With Quote
 
 
 
 
mike3
Guest
Posts: n/a
 
      05-26-2007
On May 26, 4:14 am, James Kanze <(E-Mail Removed)> 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: (E-Mail Removed)
> 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



 
Reply With Quote
 
mike3
Guest
Posts: n/a
 
      05-26-2007
On May 26, 4:14 am, James Kanze <(E-Mail Removed)> 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: (E-Mail Removed)
> 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



 
Reply With Quote
 
peter koch
Guest
Posts: n/a
 
      05-26-2007
On 26 Maj, 21:47, mike3 <(E-Mail Removed)> wrote:
> On May 26, 4:14 am, James Kanze <(E-Mail Removed)> 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

 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      05-27-2007
On May 26, 9:47 pm, mike3 <(E-Mail Removed)> wrote:
> On May 26, 4:14 am, James Kanze <(E-Mail Removed)> 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: (E-Mail Removed)
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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
signal handling and (structured) exception handling Peter C++ 34 10-17-2009 10:03 AM
python list handling and Lisp list handling Mark Tarver Python 22 04-26-2009 09:36 PM
Is faster handling hexadecimal values than handling chars? Iñaki Baz Castillo Ruby 1 04-15-2008 09:04 AM
missing overloaded operator in numeric_std Chuck Roth VHDL 2 09-10-2005 06:40 AM
Overloaded "echo" command in perl within system (backtick, exec) call Leszek Dubiel Perl 3 05-12-2004 11:43 AM



Advertisments