Error Handling

[The_Doc_Man]

I use a slightly different approach. My code usually does something like this:

ON ERROR GOTO WHOOPSIE

{main code}
GOTO FINISHSUB

WHOOPSIE:
{event logging, message boxes, not much else}
RESUME FINISHSUBERR

FINISHSUBERR:
ON ERROR RESUME NEXT
{special cleanup}
'fall through to ...

FINISHSUB:
{normal cleanup}

END SUB

The reason I do it this way is that when I have special cleanup, I don't want that done in the context of a trap handler because a trap cannot interrupt a trap. If my special cleanup can itself incur an error, I get into a really awkward situation, a "trap loop." REALLY a pain to fix. If I use tested and debugged methods of event logging and message notification, then resume in the normal code body but in an error pathway, I can immediately cancel or replace the error handler (to stop potential trap loops on cleanup).

We must remember that at least in theory, traps are queued to your process asynchronously and Access has to linearize them because a trap cannot interrupt a trap. So we have to be careful about allowing a trap to cause a condition that would signal a trap.

The reason is that the same handler that triggered the trap is STILL the declared trap handler in that context. Taking a trap is NOT a one-shot deal. The declared trap handler is part of the call frame still in effect for that subroutine.

So where does the trap go? Right back to the place that caused it (for the bad handler case). Don't worry, it will eventually stop when all the memory leaks eventually eat all of the heap space. Give it a couple of days. Of course, if you have a multi-core machine, you will be able to get enough CPU time to activate and employ task manager to kill that wild process, which might saturate one core of your CPU if you weren't doing any message boxes as part of the process.

 

[static]

The problem is that VBA has horrible error handling.

I 've always hated labels so never use goto.

In other languages you can use sytax such as

try
   ...
   return true
catch
   ...
   logerror()
   return false
end try

IMO the closest thing in VBA is

On Error Resume Next '=try
...
Select Case Err.Number
Case 0: 'all good
Case Else '= catch
End Select

And if you break subs up into smaller functions you get easily readable procedures like

pubic sub main
   If importdata Then
      If processdata Then
         If generatereport Then
            MsgBox "done"
         End If
      End If
   End If
End Sub

Public Function importdata() As Boolean
On Error Resume Next

   docmd.transferwhatever(...)

   Select Case Err.Number
   Case 0: importdata = True
   Case Else
      MsgBox "import failed"
      importdata = False
   End Select
End Function

...

 

[The_Doc_Man]

There are pros and cons to each language. You learn (if you see enough of them) that there is almost no difference between an ELSE and a GOTO to skip the code that would have been in an ELSE block, and no difference between the END IF or a target label. To me, goto-less programming is a HUGE mistake when taken to an extreme because the problem with convoluted nesting outweighs the "shortcut exit" provided by a GOTO. After about ten conditions have to be nested and the IF ladder gets really deep, it is time to understand that deep nesting is no easier to read than GOTO-based code if you use the GOTO sparingly.

This is something I've learned from programming in three different assembler languages, FORTRAN II-D and IV, ALGOL, PASCAL, P/L-1, ADA, and not less than five flavors of BASIC. I don't do C variants or JAVA variants by choice - and also because C never came up in any of the projects on which I have worked. Just as well since "pure" C is something that I think shouldn't even exist. It is too easy to incur data-typing errors because of the "looseness" of the language. I'm not so hard-nosed about C++ and advanced variants thereof.

This is clearly to be taken as an opinion, though those of you who know me know how firmly I can hold my convictions when they were earned through experience. Static, I'm betting that YOU came up through C-based and JAVA-based languages or a PASCAL-based procedural language. That's why you feel the way you do.