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, li...@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) _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
