Error handler inserter

[MacroShadow]

Does anybody know of a add-in/method to automatically insert error handling to all modules in a project.

Seth D. Galitzer has one for Access @ http://seth.galitzer.net/node/11

The MZ Tools @ http://www.mztools.com/v3/mztools3.aspx has an option to add error handling to a procedure, but it won't insert into all procedures in the project in one move.

[fumei]

I was going to suggest MZTools, but you are right, it does not insert in all procedures, in all modules.

You could VBA to insert text (i.e. lines of code) into all procedures, in all modules. But it would be tricky to be sure of WHERE. Now if you knew for sure you wanted the text |(lines of code) at the very end of all procedures, that could be done. It would take brute force.

Run through all the lines, testing the text of each, and if End Sub is found, work backwards and insert the text.

Ugly, but it could possibly work.

For any newbies, this may be a good time to again suggest you get MZTools. It is free, and has some nice features for working in the VBE (Visual Basic Editor).

[Frosty]

Wouldn't it be almost as easy (similar to another thread about VBProject and automatically doing stuff), to simply use Find/Replace in Word to do what you're talking about? You could look for "End Sub" (and Function) and put in the handler area, and then look for any "Sub " (and Function) and put the actual On Error line there.

I would be wary of this approach though, since error handling is not a one-size-fits-all kind of thing.

Although I'm intrigued by what MZTools does, there is no substitute for understanding.

MacroShadow, error handling is a *big* topic. If you want to ask conceptual questions about it, please do. I'm sure google searching would also give you some good theoretical approaches (and reasons).

As a quick example of my two most basic approaches to error trapping:

Public Sub UI_IGetRunByAButton
On Error GoTo l_err
'here the routine does stuff

l_exit:
exit sub
l_err:
' here I go to an external function for generic error trapping, passing the
' actual error object, with a number of optional parameters I may or may
' not tailor to the specific routine
resume l_exit
End Sub
'A generic replacement of the CStr function
Public Function fCStr (sVal as Variant) As String
Dim sReturn As String
On Error GoTo l_err
sReturn = CStr(sVal)
l_exit:
fCStr = sReturn
Exit Function
l_err:
'blackbox, so any errors in conversion return an empty string
sReturn = ""
resume l_exit
End Function
Two concepts there --

1. Any routine which a user can get to via clicking a button (i.e., a "top level" routine), should return some sort of messagebox letting the user know there was an error. That's the UI_ sub routine (I always preface functions available by clicking or shortcut keys with UI_)

2. A much lower level function... where I don't want a messagebox to pop up... I actually want to handle the error and continue processing.

Any generic "replace all" functionality (whether through find/replace in Word or coded by using the VBProject object model) wouldn't even be able to handle that basic difference between dealing with an error.

The general rule is that you don't want to ever present the end-user with the Microsoft generic Debug dialog. But at the same time, you don't want some errors to throw your entire routine into a tailspin. So you have to "handle" errors differently. No one-size fits all solutions for that basic concept.

[fumei]

I am in total agreement with Frosty. I was just responding as if you know what you are doing, and wanted to put a generic error trap similar to what Frosty does at the end of his procedures. l_err:
' here I go to an external function for generic error trapping, passing the
' actual error object, with a number of optional parameters I may or may
' not tailor to the specific routine
resume l_exit
End Sub
If you look at his code that he posts, he always (or just about) has this final error trap terminating procedures or functions.

Error trapping is indeed a huge subject. It is the most commonly ignored area in coding...unfortunately. It is not uncommon that in large projects for error-trapping to take up 30% (or more) of the code. And not uncommon for it to take up 50% (or more) of the thinking.

In my VBA course (when I taught it) students always groaned when I told them we were going to do a full day just on error trapping. Although that did include debugging methods.

But to show how important it is, in the last 90 minutes I gave them a task. Make any code you want, and try to error-trap to the fictional "bullet-proof". Then I tried to break it. In six years there was only ONE person would made their code bullet-proof. She was the most brilliant student I ever had.

Mind you, these were people just starting in VBA for the most part. Although MOST of them were professional programmers - which just goes to show that professional programmers can be very sloppy.

Good error-trapping comes from experience. I seriously doubt I could break Frosty's code. He is very very good. Pay attention to all his posts.

So. Yeah, it would be easier to pull your code out into text in Word, use Word (as a word processor) to do what you want, and dump the whole module back into the VBE.

[Frosty]

Thanks for the compliment, Fumei.

I'd just add... there are a lot of styles to error trapping. The one I use is simply because it was the one I was taught. You will often see what I call the "other" structure... namely:

Public Sub UI_SomeProc
On Error Goto ErrorTrap
'main routine
ErrorTrap:
Select Case Err.Number
Case 0
'no error, continue on
Case 9
'specific error, handle and try again
Resume
Case 10
'another specific error, but skip the original line that caused the error
Resume Next
'unexpected error
Case Else
Msgbox "Error in this routine" 'and give some more details
End Select
Done:
End Sub

There are many flavors... and as Fumei said, it takes time and experience to decide what is appropriate in what scenario.

But the best approach, if you are deploying your code to end-users, is
a) never present the default debug window (so all top-routines have some form of error trapping which isn't On Error Resume Next) -- but it doesn't have to be a message box. You could just as easily change the Status Bar.
b) comment any specific error trapping really well -- since you will never know more about why you are handling a specific error in a specific way than when you first code it.

[fumei]

Regarding b) - commenting - this can NOT emphasized too much!!

Assuming you will remember is foolish. You will not.

[MacroShadow]

Thanks Experts for enlightening me.

I always understood that error handling and error trapping are two separate things, handling mainly to take care of non anticipated errors and trapping to deal with the anticipated errors, please correct me if I'm wrong.
I generally insert a generic error handler after most of the development is completed (error trapping is inserted during development since I consider it part of the logic), I simply find it a lot more difficult to read the code with error handling present (it's a lot longer and tends to cause distractions in following the logic). Is this ok, or should I put in the extra effort to get used to reading the code with error handling during development?

Frosty, as usual your posts are very clear, and greatly helped me get a clear understanding of the beginning of the very basics of error handling.


In my VBA course (when I taught it) students always groaned when I told them we were going to do a full day just on error trapping. Although that did include debugging methods.

But to show how important it is, in the last 90 minutes I gave them a task. Make any code you want, and try to error-trap to the fictional "bullet-proof". Then I tried to break it. In six years there was only ONE person would made their code bullet-proof. She was the most brilliant student I ever had.

Mind you, these were people just starting in VBA for the most part. Although MOST of them were professional programmers - which just goes to show that professional programmers can be very sloppy.
WOW!!! That's scary, what are my chances of succeeding...


Regarding b) - commenting - this can NOT emphasized too much!!

Assuming you will remember is foolish. You will not.
I learned that the hard way:(

[fumei]

First of all, do not be too put off by the fact that so many could not "bullet proof" their code. Most of the time they were overly ambitious, and used WAY too much code. That is one of the reason to try and both simplify things AND "chunk" out code into reuseable and well structured portions.

An early mistake people make is putting all of the code into one huge procedure. Do not do this. If you can have a portion that is sort of independent of other portions, pull it out into its own procedure and Call it. This makes code easier to read, easier to debug, easier to reuse in another procedure.

Yes error handling and error trapping are different, and you phrased it well. Nevertheless, they are entwined within the process of having code that runs well and correctly.

I simply find it a lot more difficult to read the code with error handling present (it's a lot longer and tends to cause distractions in following the logicThis is somewhat true. It can cause distractions, but if it is done well with good comments this can be minimized. Again look at Frosty's code. I have some issue with it, but very little.

If you find it really distracting, change the flavour to that Select Case version he posted. You may find it easier to read. I think it is.

You make an interesting comment re: error trapping happens DURING development, error handling AFTER. Yes error trapping can be considered as part of logic. IMO it gets a bit blurry. Anticiapated versus non-anticipated? Hmmmm.

WOW!!! That's scary, what are my chances of succeeding...
I would say quite good actually.

[mmerlin]

Does anybody know of a add-in/method to automatically insert error handling to all modules in a project.

The MZ Tools has an option to add error handling to a procedure, but it won't insert into all procedures in the project in one move.
[/QUOTE]

I came here after google search looking to answer the exact same question... (I use MZ-Tools but inherited a very large project with minimal error handling and didn't feel like spending a hours and hours adding error handling... thinking there must be some solution out there)



Seth D. Galitzer has one for Access

OK here is why I registered, to save someone else half an hour of wasted time (possibly)

Yes this code works, yes it does insert across all forms/reports/modules

But Seth's has one fatal flaw (for me) which is you cannot really modify the error handler (like you can in MZ-Tools). You have to use his error handler which pretty much only displays a message box.

Plus it was a minor hassle getting it registered on Win2008 Server 64-bit (my dev machine). I will paste notes here for anyone who wants to register his .dll

---------------------------





The zip file dontains a single dll file which needs to be placed in your \Windows\System folder (or \winnt\system32 for NT/2K, or \Windows\system32 for you brave XP folks), and then manually registered using regsvr32.

To do this, simply open a DOS window (or command prompt) and type 'regsvr32 "VBEErrorHandler.dll"'. Leave off the single quotes, but keep the double quotes since it's a long filename.

All Office apps should be closed before you do this.

Now open a database of your choosing and then any of its modules.

You should notice a new toolbar with the error handler insertion functions,
and a new menu group under the Add-Ins menu named "C2DbFrameWiz".

In this group you will find an additional selection for "Configure Error Handler."

This is where you make change your preferences for how the add-in works.



MMERLIN'S NOTES: If installing in W2k8 server

The version of Regsvr32.exe must match the 32-/64-bitness of the dll you're trying to register. The 64-bit regsvr32 cannot load a 32-bit dll, and vice versa.

You may need explicitly call the 32-bit version of regsrv32 located in %systemroot%\SysWoW64\regsvr32.exe

{web link reference removed because I am newbie post count here!}

So in CMD if I run %systemroot% I get window of
C:\Windows

so... I tried

C:\Windows\SysWoW64\regsvr32.exe "C:\Windows\System32\VBEErrorHandler.dll"

But that didnt work so I moved the dll into C:\Windows\SysWoW64\

and ran

C:\Windows\SysWoW64\regsvr32.exe "VBEErrorHandler.dll"

that failed too because CMD was not running as elevated administrator

{web link reference removed because I am newbie post count here!}

so run CMD as Administrator

re-run
C:\Windows\SysWoW64\regsvr32.exe "VBEErrorHandler.dll"

and it worked!


Now in Access VBE I have a new toolbar from Seth

But sadly I cannot modify the error handling template :-(

Maybe I need to buy one of FMS tools again. I remember years ago they had some global error handler inserter thing (I had two versions of their enterprise suite for 97 and 2000)