expanding an error description

DunbarX at aol.com DunbarX at aol.com
Wed Jun 10 17:46:01 EDT 2009


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.
> 
> 




**************
Download the AOL Classifieds Toolbar for local deals at your 
fingertips. (http://toolbar.
aol.com/aolclassifieds/download.html?ncid=emlcntusdown00000004)



More information about the use-livecode mailing list