CBFalconer wrote:
Frank Heckenbach wrote:
... snip ...
Fortunately, most I/O errors (e.g.) in Pascal are not signaled via function results in the first place.
I have always considered this an error in Pascals basic design, at least as far as things that do not fit the format are concerned. Consider:
read(intvar);which has to cause an i/o error and usually program abort (barring other extensions) if the interactive input is not properly formatted.
I agree. In fact, here's where I prefer (in many situations) Borland's `{$I-}'/`IOResult' extension since it allows me to handle errors from a bunch of I/O statements together. Though exceptions (yet another extension) might be even better in the long run ...
So I have always provided (as an extension) an alternative standard function:
FUNCTION readx(something) : boolean;which returns true on a formatting error, and extends to reals, etc. just as does the normal read function. Unlike read, it cannot be used as shorthand for multiple reads. Thus interactive usage is normally:
IF readx(something) THEN correctiveaction ELSE BEGIN (* all is well *) END;with the knowledge that the offensive character is in input^.
BP has `Val (StringValue, TargetVariable, ErrorPosition)'. I usually use this, but I find the procedure-style usage rather clumsy often (the need for an extra variable which is usually just tested in a following conditional).
Therefore I've considered implementing such a Boolean function -- though my thoughts were more about parsing from a string, just like `Val' (it's more general -- you can always read from a file to a string first, but if you have the value in a string already, it would be rather inefficient to write it to a file first), and I'd have the result value the opposite way (True for success) ...
So my proposal is to add (now or later):
function String2Num(???) (const s: String; var n: <numeric type>): Boolean;
Comments?
Frank