Results 1 to 5 of 5
  1. #1
    Join Date
    Apr 2004
    Posts
    66

    Unanswered: Error Handling Code...

    I think this is a quick and easy thing, and am hoping someone can help me.

    When I loop through my stores to send out the reports, some stores have no data, so I have a message stating no data, therefore, no report. My code sees this as an error and stops looping to the next store.

    Is there a way around this? I tried putting the error statement in the loop, but don't know what to change in it to make it work...

    Right now, my error code states:
    Err_Command10_Click:
    MsgBox Err.Description
    Resume Exit_GetRecipient

    So, of course, it quits. I tried telling it to just 'resume' but then it looped continuously on that record. What is the proper code to tell it to move to the next iteration?

    Thanks!

    Susie

  2. #2
    Join Date
    Dec 2002
    Location
    Préverenges, Switzerland
    Posts
    3,740
    a possible method to a fix.

    change
    MsgBox Err.Description
    to
    MsgBox Err.Description,,"Error " & err.number

    run again and note the number.

    now use slightly smarter error handling along the lines of:

    Err_Command10_Click:
    select case err.number
    case whatEverNumberYouGotInTheEarlierMessagebox
    resume next 'or resume somewhere else useful in your code
    case else
    MsgBox Err.Description
    Resume Exit_GetRecipient
    end select

    ...and at this stage you pray that err.number is SPECIFIC to your no-data error.

    izy
    currently using SS 2008R2

  3. #3
    Join Date
    Dec 2003
    Posts
    268

    Try this

    First Off. Name your controls with viable names. Ambiguity in form design can be a hinderence in the long run, especially with trouble shooting in the future.

    Secondly, We need more information to be able to trouble shot this. How are you itterating through your customers. Through a Recordset?

    With some more information I can get you a better answer

  4. #4
    Join Date
    Apr 2004
    Posts
    66
    Quote Originally Posted by mjweyland
    First Off. Name your controls with viable names. Ambiguity in form design can be a hinderence in the long run, especially with trouble shooting in the future.

    Secondly, We need more information to be able to trouble shot this. How are you itterating through your customers. Through a Recordset?

    With some more information I can get you a better answer

    User is selecting multiple stores using multiselect in a list. The code then looks at each one, and if selected, prints the associated report. The problem comes when the report is empty (as no one wants to email their customer a blank report). In the report, OnEmpty, sends a message stating no data, and cancels the report. This error then stops the looping all together.

    You're right of course, that I need to be better about naming things - it's still my downfall! I'll work harder on it!!

    I like the solution of the above post, except that I'm worried about other errors (for example, if I cancel sending the email, it also stops everything.

    Is it wrong to simply send an error to 'Resume Next' and not worry about the error?

    THanks!

    Susie

  5. #5
    Join Date
    Dec 2002
    Location
    Préverenges, Switzerland
    Posts
    3,740
    Is it wrong to simply send an error to 'Resume Next' and not worry about the error?
    ...it is entirely your decision.

    IF
    you have one or several err.numbers that you expect to occur but that you want to be non-fatal (your empty report is a perfect example - you expect it to happen but you don't want it to junk the rest of your reports)
    AND
    these "anticipated errors" raise an err.number that is specific to a given anticipated error (e.g. empty-report and only-empty-report throw error 9999)
    THEN
    not only is it not-wrong, but it is extremely-correct to handle these errors separately.

    resume next may not be the correct action... depends on your code details: most likely the best place to resume is just before your loop counter increments. find the right spot in your code to add a
    resumeAfterEmptyReport:
    label and goto there.

    a couple of other general thoughts about error handling:

    you are allowed as many
    on error goto thisLabel
    statements in a procedure as you want, so you can use different handlers in different sections of your code.

    the all-errors-exit-gracefully approach can often hinder debugging. one way around this is a global constant inDebugMode and then all your error initialisations read
    if not inDebugMode then on error goto myErrorHandler
    redefining the constant allows you to turn error handling on/off at will during your debugging effort

    all the foregoing supposes that the empty report throws an err.number specific to empty reports (i have absolutely no idea if this is true) ...as a potentially better approach, instead of waiting to handle errors, consider weeding out the empty-reports at the query stage so that the problem goes away completely.

    izy
    currently using SS 2008R2

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •