I came across this while modifying an old ASP application:


ivalue = CDATE(ivalue)

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

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, 2011 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, 2011 at 23:26
  • 1
    Based on this code, yes, I have seen (and developed) VBScript. Feb 7, 2011 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, 2011 at 16:20

4 Answers 4


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.


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.


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, 2011 at 22:07

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 {
    } catch (NullPointerException e) {
      logger.info("Caught null pointer exception from longAndObscureMethod"
        + " because all field values from transaction X have been processed");

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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