|
|
 |
 |
 |
 |
Is this a good idea? (Error handling with overloaded operators)
Hi. Is this a good idea?: <begin code> /* Addition operator: += */ const BigFix &BigFix::operator+=(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 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: james.ka@gmail.com Conseils en informatique oriente objet/ Beratung in objektorientierter Datenverarbeitung 9 place Smard, 78210 St.-Cyr-l'cole, France, +33 (0)1 30 23 00 34
On May 26, 4:14 am, James Kanze <james.ka@gmail.com> 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: james.ka @gmail.com > Conseils en informatique oriente objet/ > Beratung in objektorientierter Datenverarbeitung > 9 place Smard, 78210 St.-Cyr-l'cole, France, +33 (0)1 30 23 00 34
On May 26, 4:14 am, James Kanze <james.ka@gmail.com> 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: james.ka @gmail.com > Conseils en informatique oriente objet/ > Beratung in objektorientierter Datenverarbeitung > 9 place Smard, 78210 St.-Cyr-l'cole, France, +33 (0)1 30 23 00 34
On 26 Maj, 21:47, mike3 <mike4@yahoo.com> wrote:
> On May 26, 4:14 am, James Kanze <james.ka @gmail.com> 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
On May 26, 9:47 pm, mike3 <mike4@yahoo.com> wrote:
> On May 26, 4:14 am, James Kanze <james.ka @gmail.com> 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: james.ka@gmail.com Conseils en informatique oriente objet/ Beratung in objektorientierter Datenverarbeitung 9 place Smard, 78210 St.-Cyr-l'cole, France, +33 (0)1 30 23 00 34
|
 |
 |
 |
 |
|