2

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?

  • 2
    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 7 '11 at 21:50
  • 1
    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 7 '11 at 23:26
  • 1
    Based on this code, yes, I have seen (and developed) VBScript. – Austin Salonen Feb 7 '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 8 '11 at 16:20
5

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.

1

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.

0

I thought Error Driven Development was:

1) Get error code.

2) Type in Google and find solution.

3) Implement solution.

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

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();
    }
  }
  ...
}

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.