...
>I wonder how that can happen.
>
It is very simple - I feel I can do the same - you implement (the first
part of) a new feature, you make some preliminary tests, and let that
feature living its own life.
...
It's more like:
- Someone says "we need some code to turn a string into a number"
- Programmer writes the code and tests it. It works perfectly, _assuming_
_the_original_string_is_a_number_.
- Documentation writer says "it turns a string into a number."
- An outside user gives it a string with a leading space. Either:
- it works, because the original code skipped the space for
some reason (possibly some code written within the organization
didn't trim the extra space first0, or
- it doesn't work and generates a bug report
- The code gets fixed to properly trim leading spaces.
- This may or may not make it into the documentation.
Now, someone else hands it an obviously broken string ("&h ff" is, in
my humble opinion, obviously broken). It returns a weird result. GIGO.
The real issue here is that there is no specification of what the
behavior is for strings that aren't numbers. Does it throw an
exception? Is it undefined? Is it indeterminate?
This is an area that was (and is) addressed really well in the C
language specification.
>From over 30 years' experience in programming, my approach is to watch
out for such murky areas and simply never go there. Does the
L.R. clearly state what happens with a broken string? No. So NEVER
GIVE IT ONE. It's my responsibility as a programmer to sanitize data
and there is no way that someone at RealSoftware could ever know what
action I want to take if the data isn't meaninful.
Craig
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
