expanding an error description

[Phil Davis]

Right you are! And if I had written the app, that's how it would work. 
But right now it's more expedient for me to fix error reporting than to 
go through the system (it's really a set of apps) and change untold 
dozens of data entry points.

Thanks Craig -
Phil


DunbarX at aol.com wrote:
> It seems far more important, and far easier in the long run, to validate 
> entry data before it gets anywhere close to being mishandled. Check to see if 
> numbers are numbers, dates are dates, etc. I would bet that the errors fall 
> into a very few categories, and these can all be screened early on.
>
> Many newbie (ahem) error posts are of just this type, for example, an 
> errant char in the second line of a field, and only the first line is visible, 
> where the contents of the field has some math done to it. So another level of 
> checking that I use all the time is to act only on line 1 of the field that 
> purportedly has valid data in it. But even this should really be vetted at 
> entry time.
>
> Craig Newman
>
> In a message dated 6/10/09 4:34:53 PM, lists at mangomultimedia.com writes:
>
>
>   
>>> I help maintain some software whose users can sometimes generate an 
>>> error by entering malformed data in a given field (e.g. non-numeric 
>>> data where math is done after data is moved into temp variables). 
>>> What I'm looking for is some code that displays the contents of the 
>>> variables containing malformed data. However, the error handling 
>>> code is in a libraried stack so I assume I can't just "get the 
>>> variableNames" from there and work with those, since the error 
>>> occurred in the script of a different stack.
>>>       

-- 
Phil Davis

PDS Labs
Professional Software Development
http://pdslabs.net