Should I achieve validation by handling errors in classic ASP?

Question

I came across this while modifying an old ASP application:

ON ERROR RESUME NEXT

ivalue = CDATE(ivalue)

IF err.number > 0 THEN
  ivalue = CDATE(date)
END IF
err.clear

This doesn't look like good practice. What is the purpose of doing it this way, and is there a better way to go about it? For example, I would've just used ISDATE(): is there something I'm missing?

That is just poor man's exception handling from old school MS land. Though the way that the person is using it is questionable. — Pemdas, Feb 07 '11 at 21:50
Unfortunately, with ASP, that was the only way in some cases to NOT throw an ugly exception to your user when an error occurred. Unfortunately it required you to also check your values... — Chris K, Feb 07 '11 at 23:26
Based on this code, yes, I have seen (and developed) VBScript. — Austin Salonen, Feb 07 '11 at 23:48
"Have you ever seen something like this?" Can you rephrase this question so that it can be answered with something other than a "yes/no"? What are you trying to find out? What are good error handling practices in classic ASP? Something else? — Marcie, Feb 08 '11 at 16:20

score 5 · Accepted Answer · answered Feb 07 '11 at 21:48

In some cases (depending on the API etc.) it's easier to try something and check the result (catch an exception or whatever) than check the parameter; I'm not sure about the given VB program but if it is a common case that ivalue is not a valid parameter for CDATE, than it's IMO better to do it like in the example, i.e. ON ERROR RESUME NEXT, and check err.number, instead of letting CDATE throw an exception and catch it. Because exceptions are for exceptional circumstances only.

score 1 · Answer 2 · answered Feb 07 '11 at 22:42

Earlier versions of classic VB didn't leave you with much else to work with. In your example you could try to parse the imput manually before hand, but the performance on this sort of error code usually was many times anything you could do with parsing manually and tryparse was something that just was not available yet.

Checking and recovering from the bad value after skipping past with the resume next rather than just plowing ahead anyway was a sign of a good developer at the time.

score 0 · Answer 3 · answered Feb 07 '11 at 21:40

0

I thought Error Driven Development was:

1) Get error code.

2) Type in Google and find solution.

3) Implement solution.

answered Feb 07 '11 at 21:40

Martin Blore

4,645
5
29
35

1

The error code better be in plain text then instead of a 32-bit value. – Feb 07 '11 at 22:07

Péter Török · Answer 4 · 2011-02-07T22:04:35.640

If using exceptions for flow control counts, then yes :-(((

We have code in our legacy app which - out of the top of my head - looks something like this:

class SomewhereDeepInTheCallHierarchy {
  ...
  public void longAndObscureMethod(...) {
    ...
    for (...) {
      String someValue = getFieldValueFromServerTransactionResponse(...);
      // lots of code...
      if (someValue.equals(...)) ...
    }
    ...
  }
  ...
}

class MuchHigherLevel {
  ...
  public void someMethod(...) {
    ...
    try {
      ...
      callLongAndObscureMethodIndirectly();
      ...
    } catch (NullPointerException e) {
      logger.info("Caught null pointer exception from longAndObscureMethod"
        + " because all field values from transaction X have been processed");
      doTheNextProcessingStep();
    }
  }
  ...
}

Should I achieve validation by handling errors in classic ASP?

4 Answers4