Re: How to handle crashes?
On Sat, May 31, 2003 at 08:25:41PM +0200, Juergen Luethje wrote:
>
>
> Hi Jim, you wrote:
>
> <snip>
>
> > It's an interesting suggestion. I'd think, that 1/0 should return nan, that
> > invalid assignments to variables would simply be ignored, and that invalid
> > slices of a sequence would return {} ... but those are just the details.
> >
> > The basic concept, looks ok to me, tho it seems to be not the best way. My
> > lib
> > will just flatly return -1 on error, and then you have to check the variable
> > eu_errno to see what the error was (you'd have to check eu_errno every time
> > if -1 is a valid return value btw).
>
> That's exactly the reason, why I'd prefer using a value as a flag for an
> invalid result, that never can be a valid number or sequence (such as
> NIL/NAN/UNKNOWN/UNDEFINED), rather than -1. This is especially important
> for writing generic routines.
Yes, but its very hard to find one like that.
I used to like to do what DC did in Py:
global constant UNDEFINED = {-102354, -102354}
He called it PyUndef and used different numbers tho, but the general concept
(use an ugly looking sequence that is unlikely to every be a valid result)
still works.
> That's why I was happy when I discovered, that NAN can be returned from
> user defined functions.
Shouldn't have, since NAN can be a perfectly valid return value.
> And that's why I was unhappy, when I recently
> read on this list, that this self-defined NAN can't be used reliable.
The reason behind that, is that there is more than one NAN.
You can get a NAN from tan(), power(), -inf/inf, ...
And, each way of calculating NAN gives a different NAN.
What should be done, is to do this.
global constant
divNAN = -inf/inf,
powNAN = power(2, inf),
tanNAN = --however you get a NAN from tan()
...etc for every possible way of calculating NAN.
So, that, divNAN is reliable when using NANs from division, but not with
comparisons
to tanNANs, for example.
Then, you can choose one NAN, to use as the return value ... as long as its
always the same NAN there is no problem. (Except of course, that NAN could be
a valid return value ... but so could {-102354, -102354}, so theres no good
way of getting around that.)
>
> > That way, at least the code actually _KNOWS_ that there was an error.
>
> I also regard this as important.
I based my errhandle.e lib, on how C stdlib functions use a global errno to
return errors.
jbrown
>
> > jbrown
>
> Best regards,
> Juergen
>
> --
> /"\ ASCII ribbon campain |
> \ / against HTML in | Money is the root of all evil.
> X e-mail and news, | Send 20 Dollars for more info.
> / \ and unneeded MIME |
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
>
--
/"\ ASCII ribbon | http://www.geocities.com/jbrown1050/
\ / campain against | Linux User:190064
X HTML in e-mail and | Linux Machine:84163
/*\ news, and unneeded MIME |
|
Not Categorized, Please Help
|
|
