Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
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 Kaminski 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

4 Answers 4

up vote 5 down vote accepted

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.

share|improve this answer

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.

share|improve this answer

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();
    }
  }
  ...
}
share|improve this answer

I thought Error Driven Development was:

1) Get error code.

2) Type in Google and find solution.

3) Implement solution.

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

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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