«

Hi.
(crossposted because the program is in C++ and some C++-related
elements are discussed, hence comp.lang.c++, plus general program
design questions are asked, hence comp.programming.)

I'm making this bignum package in C++. I'm wondering though on how to
handle the errors. Right now most operations routines return error
codes if they fail -- but some routines they use inside them, or
overloaded operators, will throw exceptions on failure. For example,
the C++ standard library routines that get used, for instance to copy
vectors or pieces of vectors of digits. These may throw on failure.
Would it be good to then use a consistent system of error handling
where bignum ops always throw exceptions instead of returning error
codes, instead of having some failures throw exceptions and other
failures release error codes (the exceptions would be coming from the
standard lib. functions for example)? What is the "ideal" plan for a
bignum package, anyway?

mike3 wrote:
> Hi.
> (crossposted because the program is in C++ and some C++-related
> elements are discussed, hence comp.lang.c++, plus general program
> design questions are asked, hence comp.programming.)
>
> I'm making this bignum package in C++. I'm wondering though on how to
> handle the errors. Right now most operations routines return error
> codes if they fail -- but some routines they use inside them, or
> overloaded operators, will throw exceptions on failure. For example,
> the C++ standard library routines that get used, for instance to copy
> vectors or pieces of vectors of digits. These may throw on failure.
> Would it be good to then use a consistent system of error handling
> where bignum ops always throw exceptions instead of returning error
> codes, instead of having some failures throw exceptions and other
> failures release error codes (the exceptions would be coming from the
> standard lib. functions for example)? What is the "ideal" plan for a
> bignum package, anyway?

I like this paper about exception handling:
http://neil.fraser.name/writing/exception/

On Nov 16, 11:14 am, mike3 <mike4...@yahoo.com> wrote:
> Hi.
> (crossposted because the program is in C++ and some C++-related
> elements are discussed, hence comp.lang.c++, plus general program
> design questions are asked, hence comp.programming.)
>
> I'm making this bignum package in C++. I'm wondering though on how to
> handle the errors. Right now most operations routines return error
> codes if they fail -- but some routines they use inside them, or
> overloaded operators, will throw exceptions on failure. For example,
> the C++ standard library routines that get used, for instance to copy
> vectors or pieces of vectors of digits. These may throw on failure.
> Would it be good to then use a consistent system of error handling
> where bignum ops always throw exceptions instead of returning error
> codes, instead of having some failures throw exceptions and other
> failures release error codes (the exceptions would be coming from the
> standard lib. functions for example)? What is the "ideal" plan for a
> bignum package, anyway?

Personally I prefer exceptions to error codes. Error codes could
remain undetected, causing an error to propagate.
Exceptions cannot go undetected: or they can but you have to
explicitly code that.

If an undetected error in the package could cause a big mess, then I
would report the error using an exception.
I prefer an application crash with a big bang because of an uncaught
exception than a big mess that acts nicely and goes undetected.

I also think that an application is easier to read when its functions
return the intended return value with the "return" statement, instead
of saving it in some parameter passed by reference.

You could also implement some macros that report the stack trace
traveled by the exception (chained exceptions, or http://www.ddj.com/cpp/191100567
without chaining the exceptions)

My 3 USD cents (or 2 eurocents)

On 2007-11-16 05:14:46 -0500, mike3 <> said:

> Hi.
> (crossposted because the program is in C++ and some C++-related
> elements are discussed, hence comp.lang.c++, plus general program
> design questions are asked, hence comp.programming.)
>
> I'm making this bignum package in C++. I'm wondering though on how to
> handle the errors. Right now most operations routines return error
> codes if they fail -- but some routines they use inside them, or
> overloaded operators, will throw exceptions on failure. For example,
> the C++ standard library routines that get used, for instance to copy
> vectors or pieces of vectors of digits. These may throw on failure.
> Would it be good to then use a consistent system of error handling
> where bignum ops always throw exceptions instead of returning error
> codes, instead of having some failures throw exceptions and other
> failures release error codes (the exceptions would be coming from the
> standard lib. functions for example)? What is the "ideal" plan for a
> bignum package, anyway?

You should begin by listing the possible errors. Off the top of my
head, I only see two: running out of memory, and attempting to divide
by zero. The first throws an exception, and you can't fix it, so don't
try. The latter should probably also throw an exception.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

mike3 <> wrote in news:fd846b87-1e40-482e-8318-
:

> Hi.
> (crossposted because the program is in C++ and some C++-related
> elements are discussed, hence comp.lang.c++, plus general program
> design questions are asked, hence comp.programming.)
>
> I'm making this bignum package in C++. I'm wondering though on how to
> handle the errors. Right now most operations routines return error
> codes if they fail -- but some routines they use inside them, or
> overloaded operators, will throw exceptions on failure. For example,
> the C++ standard library routines that get used, for instance to copy
> vectors or pieces of vectors of digits. These may throw on failure.
> Would it be good to then use a consistent system of error handling
> where bignum ops always throw exceptions instead of returning error
> codes, instead of having some failures throw exceptions and other
> failures release error codes (the exceptions would be coming from the
> standard lib. functions for example)? What is the "ideal" plan for a
> bignum package, anyway?

The rule of thumb that I use is to ask myself if what I want is stack
unwinding or not. That is, do I expect my immediate caller to be able
to handle this problem, or is it more likely to be handled at a higher
level. If I don't expect my immediate caller to be able to handle it,
then exceptions are the best answer for error handling. If I expect my
immediate caller to be able to fix it, then error codes is the way to
go. Sometimes you end up with a sometimes yes, sometimes no sort of
answer and you then pick your favorite.

Exceptions require a certain amount of overhead to throw, so if you
expect to be having the error a lot, then throwing an exception may not
be your best alternative. Of course, if you expect the error a lot, it
is also usually the case that the immediate caller can handle the
problem and move on, so the first guideline catches that, but it is
still a concern.

HTH,
joe

On Nov 16, 7:00 am, Joe Greer <jgr...@doubletake.com> wrote:
> mike3 <mike4...@yahoo.com> wrote in news:fd846b87-1e40-482e-8318-
> dfcf73b42...@s12g2000prg.googlegroups.com:
>
>
>
>
>
> > Hi.
> > (crossposted because the program is in C++ and some C++-related
> > elements are discussed, hence comp.lang.c++, plus general program
> > design questions are asked, hence comp.programming.)
>
> > I'm making this bignum package in C++. I'm wondering though on how to
> > handle the errors. Right now most operations routines return error
> > codes if they fail -- but some routines they use inside them, or
> > overloaded operators, will throw exceptions on failure. For example,
> > the C++ standard library routines that get used, for instance to copy
> > vectors or pieces of vectors of digits. These may throw on failure.
> > Would it be good to then use a consistent system of error handling
> > where bignum ops always throw exceptions instead of returning error
> > codes, instead of having some failures throw exceptions and other
> > failures release error codes (the exceptions would be coming from the
> > standard lib. functions for example)? What is the "ideal" plan for a
> > bignum package, anyway?
>
> The rule of thumb that I use is to ask myself if what I want is stack
> unwinding or not. That is, do I expect my immediate caller to be able
> to handle this problem, or is it more likely to be handled at a higher
> level. If I don't expect my immediate caller to be able to handle it,
> then exceptions are the best answer for error handling. If I expect my
> immediate caller to be able to fix it, then error codes is the way to
> go. Sometimes you end up with a sometimes yes, sometimes no sort of
> answer and you then pick your favorite.
>
> Exceptions require a certain amount of overhead to throw, so if you
> expect to be having the error a lot, then throwing an exception may not
> be your best alternative. Of course, if you expect the error a lot, it
> is also usually the case that the immediate caller can handle the
> problem and move on, so the first guideline catches that, but it is
> still a concern.
>
> HTH,
> joe

And that last part is the thing. See, for the bignum package, there
are 3 possible types of errors: overflow, out of memory, divide by
zero.

The main concern is because the standard library functions (in
this case, "vector") may throw an exception if they fail, yet the
bignum routines return error codes for errors that are produced on
their level, and isn't that mixing two types of error handling in a
precarious way?

Also, the overflow and divide-by-zero conditions may occur more
commonly in this than you might think, at least with certain
specific types of fractals. For example, consider the iteration
of z = sin(z) on the complex plane. It may diverge wildly --
tetrationally,
to be precise -- and hence hit the ceiling real quick like you
wouldn't believe. If the "bailout" value (threshold for when the
number is considered large enough to be considered "diverged"),
is set high enough, this will max out pretty quick, generating
an overflow error. Of course once this is caught the iteration
algorithm should return that the point diverged and halt calculation,
so for each pixel there may not be a significant performance loss
even if the overflow is signaled via exception, as the loop does
not continue.

On 16 Nov., 11:14, mike3 <mike4...@yahoo.com> wrote:
> Hi.
> (crossposted because the program is in C++ and some C++-related
> elements are discussed, hence comp.lang.c++, plus general program
> design questions are asked, hence comp.programming.)
>
> I'm making this bignum package in C++. I'm wondering though on how to
> handle the errors. Right now most operations routines return error
> codes if they fail -- but some routines they use inside them, or
> overloaded operators, will throw exceptions on failure. For example,
> the C++ standard library routines that get used, for instance to copy
> vectors or pieces of vectors of digits. These may throw on failure.
> Would it be good to then use a consistent system of error handling
> where bignum ops always throw exceptions instead of returning error
> codes, instead of having some failures throw exceptions and other
> failures release error codes (the exceptions would be coming from the
> standard lib. functions for example)? What is the "ideal" plan for a
> bignum package, anyway?

For your application, I see no choice but exceptions.
First, if you want to be able to write your bignum expressions in a
natural way, e.g. for using operator overloading, an exception is the
only way to throw an error. operator* can not return an errorcode, and
you would have to use some ugly hack - e.g. by setting a global error-
variable.
The second reason is that a library in general should use exceptions
as the default error-handling mechanism as it is unlikely that the
error can always be handled locally. This second point is not an
universal truth, but the result of my experience in that area.

/Peter

On 2007-11-16 19:23:39 -0500, peter koch <> said:

>
> For your application, I see no choice but exceptions.
> First, if you want to be able to write your bignum expressions in a
> natural way, e.g. for using operator overloading, an exception is the
> only way to throw an error. operator* can not return an errorcode, and
> you would have to use some ugly hack - e.g. by setting a global error-
> variable.

Or use the hack that floating-point math typically uses: return a
special value, not-a-number, that persists through subsequent
arithmetic operations. Then the user just has to check for it at the
end.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

On 17 Nov., 01:27, Pete Becker <p...@versatilecoding.com> wrote:
> On 2007-11-16 19:23:39 -0500, peter koch <peter.koch.lar...@gmail.com> said:
>
>
>
> > For your application, I see no choice but exceptions.
> > First, if you want to be able to write your bignum expressions in a
> > natural way, e.g. for using operator overloading, an exception is the
> > only way to throw an error. operator* can not return an errorcode, and
> > you would have to use some ugly hack - e.g. by setting a global error-
> > variable.
>
> Or use the hack that floating-point math typically uses: return a
> special value, not-a-number, that persists through subsequent
> arithmetic operations. Then the user just has to check for it at the
> end.
>
> --
> Pete

Right - that is also a solution, if you call it a hack. I tend to
agree when we talk about NaN

/Peter

On 2007-11-16 19:27:37 -0500, Pete Becker <> said:

> On 2007-11-16 19:23:39 -0500, peter koch <> said:
>
>>
>> For your application, I see no choice but exceptions.
>> First, if you want to be able to write your bignum expressions in a
>> natural way, e.g. for using operator overloading, an exception is the
>> only way to throw an error. operator* can not return an errorcode, and
>> you would have to use some ugly hack - e.g. by setting a global error-
>> variable.
>
> Or use the hack that floating-point math typically uses: return a
> special value, not-a-number, that persists through subsequent
> arithmetic operations. Then the user just has to check for it at the
> end.

This solution sounds elegant, but oh boy is it hard to find where in
the possibly long and convoluted sequence of calculations did the
illegal operation originated!

And why persist in the looong computation once you've reached a NaN already?

I suggest just throw an exception and end the misery early. Moreover,
debuggers can be setup to break upon an exception being thrown. Or
with the proper API's (system dependent), you can dump the call-stack
at runtime in the exception class constructor.

--

-kira