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?

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,685

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