On May 9, 2006, at 10:32 AM, Craig A. Finseth wrote:
...
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.
This is what exceptions are for.
But the behavior of Val is reasonably well-documented; it attempts to
interpret the passed string as a number, and returns 0 if it cannot.
That Val("&h ff") returns 255 is presumably a consequence of the
parsing algorithm, which I would guess calls Trim on the string,
after first stripping the prefix, if present.
Of course, the Real Programmer's solution is to write one's own Val
function that behaves "correctly".
Charles Yeomans
_______________________________________________
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>
