How to capture the procedure name in error trapping.

[Adam Tippelt]

Currently I've expanded on the code provided by Rob Henderson in the download file here: http://www.vb123.com/toolshed/04_acc...orhandling.htm

This code allows you to provide detailed error trapping to the user. It will currently print out the error number, description, and form that created the error.
As well as this, the code will allow you to automatically record these errors in a table.

I'm trying to also find a way to expand on just being told which form has created the error - I would like a way to record the procedure that has called the error.

My problem is actually calling the error function from the procedures. Currently the error code looks like this:

'Error handling - see mdlError module.
DeleteTest_Click_Err:
    Call ErrorLog(Err.Description, Err.Number, Me.Name)
    Resume DeleteTest_Click_Exit

What's missing is the procedure reference, it should say something like:

'Error handling - see mdlError module.
DeleteTest_Click_Err:
    Call ErrorLog(Err.Description, Err.Number, Me.Name, Me.ProcedureName)
    Resume DeleteTest_Click_Exit

Obviously, "Me.ProcedureName doesn't exist, but what I'm missing is the right call to capture the procedure name. Does such a thing exist? Is there a simple implementation for this? I've done all the code in the mdlError module to handle the procedure name, it's just a way of getting the name in the first place!
EDIT: I was looking for a generic way to do this with a "one fits all" solution, as I don't really fancy going through 500+ procedures to manually hard code each individual procedure name into the error coding, when find + replace could do this automatically.

Here's hoping this is another obviously simple question! :)

Thanks in advance.

[Lysander]

Hi Adam,

I have done a search on the net and the answer to this question seems to be no, no simple way, you have to manipulate the stack! I did find product that does this for you, called vbWatchdog, which costs £45.

There is another solution. I wrote an article here that implents global error handling in all procedure automatically. I never write any error handling now at all. When I have finished the days coding, I run my routine and it puts all the error handling in.

Now, my point is that my code, at the time of generating the error handling, knows the name of the procedure it is modifying, and so you could modify my code to add the prodcedure name to your own error handling.

Now, how do I provide a link to my article?
It's called
"Automatic Error Handling in Access"
http://bytes.com/topic/access/insigh...andling-access

[NeoPa]

Unfortunately the Err object seems to have no reference to the line number that the error occurred on. Otherwise you could reference Me.Module.ProcOfLine(<ErrLine>, lngProcType) where lngProcType is a Long which takes a returned value of the type of procedure returned.

This technique may still prove useful but I see no way to tie it directly to the error line I'm afraid. Even if the concept of the <Current Line> were available anywhere this could be used, as the error handler typically runs within the same procedure. Nothing found there either I'm afraid.

[Adam Tippelt]

My search of the internet came up with the answer of no as well, but I figured I'd ask the experts here as well.
This functionality is just one of those "little extras" that are nice to have, but I certainly don't want to pay £45 for it!

I've heard of automatic error coding before, just never really looked into it. I had a quick skim of your article and it looks rather informative, so i'll have a closer read of that and see if that can help.

Thanks Lysander.

Adam.

[Adam Tippelt]

Yes NeoPa, it's a shame that no line numbering exists as a standard for VBA (without using mods), as it would be useful just when writing code...

[Lysander]

Adam, I could not work without the error handling code I developed. Well, I could, but it would take ages and probably loads of typo mistakes. What I posted here was a very basic error handler, but it can be enhanced for all sorts of conditions.

If you think it could help you, I would be more than happy to enhance it for you, in my spare time.

One thing is missing from that system, and that is a bit of code to strip out all existing error handling so that it could be replaced with the new one. Something I should work on one day:)

[NeoPa]

I have to say that it seems a rather strange omission from the Err object. Having said that, I see too many instances of members saying Access or Microsoft have missed the obvious when they are simply aware of too little to judge, not to have a suspicion that this is the case here for me. A fuller understanding often throws new light on matters. In this case I suspect that, as Access projects can be run without the original code in text form even being available, it may be quite inappropriate to provide such information. I can't know of course.

[TheSmileyCoder]

I have also myself found it a bit odd, seing as access obviously knows where the error occured (otherwise you couldn't do a Resume in your error handler)

I use this code myself.

Public Sub doStdErrMsg(Optional strProcName As String, Optional strExtra As String)
'*******************************************************************
' Purpose:   To simplyfy the code for handling unhandled errors
'            I.e. the errors that are not expected.
'            This simply gives an easy and consistent msgbox in
'            case of errors
'
' Requires:  The strProjectName constant must be defined
'
' Input:     [strProcName]: The Name of the function in which the
'                           error has occured
'
' Output:    A msgbox informing user of error
'*******************************************************************
 
    'Compose message
        Dim strMsg As String
        Dim strTitle As String
        strMsg = "An unexpected error [" & Err.Number & "] has occured"
 
    'If proc name was supplied, include it in msg and titel
        If strProcName & "" <> "" Then
            strMsg = strMsg & " inside '" & strProcName & "'."
            strTitle = strProjectName & ": Error in " & strProcName
            Else
            strTitle = strProjectName & " error"
        End If
 
    'Add description to error message
        strMsg = strMsg & vbNewLine & Err.Description
 
    'If extra is provided add it
        If strExtra & "" <> "" Then
            strMsg = strMsg & vbNewLine & strExtra
        End If
    'Post it
        MsgBox strMsg, vbOKOnly + vbExclamation, strTitle
End Sub

Making my error handling look something like this:

Err_Handler:
  If Err.Number=71 then
    'Do something
  elseIF Err.Number=91
    'Do somerhing else
  Else
    DoStdErrMsg Me.Name & "_Unload"
    Goto Exit_Sub
  End if

Basicly this means that if an unexpected error occurs (One that I haven't predicted) I can handle it somewhat gracefully without writing verbose code.

[Adam Tippelt]

@Lysander: You're probably right - it took me hours to add in all the error trapping - think I added in around 2000 lines for trapping alone.

@NeoPa: One man's madness is another man's method - I'm sure Microsoft have their reasons for not including this obvious functionality...it's just annoying that they haven't...

@Smiley: You've referred strProcName as though you can capture the procedure name that caused the error, yet I don't see how you would obtain that detail in your code, or where it's actually assigned as the strProcName value?

Perhaps I am misreading what you've put, but your code looks similar to what I'm using and when I tried adding a strProcName variable I couldn't assign a value.

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

It would appear that the simple answer I was after doesn't exist, which is annoying because I now have an error occurring that hides behind a handled error when I tell it to break on all error...

Ah well - I shall persevere!

Thanks all.

[TheSmileyCoder]

Adam Tippelt:
@Smiley: You've referred strProcName as though you can capture the procedure name that caused the error, yet I don't see how you would obtain that detail in your code, or where it's actually assigned as the strProcName value?

strProcName is not something I obtain automatically I am afraid. Its an argument I pass as the example shows.

The main purpose is that I dont have to write a msgbox command each time, with title and the works, but simply write a short message in doStdErrMsg.

[NeoPa]

Ironically enough, I find the most helpful step while debugging is to disable any breaking in the code. This can most easily be done by setting the option to 'Break on all errors'. That way, the line that caused the code to crash is highlighted and the full standard error details are shown.

Released code should probably be run under 'Break in class modules'.

PS. Notice Smiley's second block of code. Line #7 calls the procedure and passes a value that is specific to where it is called from. Other calls will pass their own specific values, but that example is clearly from the form's Load event procedure. I'm afraid it doesn't do everything you want, but it can be a basis for making what you want easier to achieve.

[TheSmileyCoder]

I know what you mean NeoPa, allthough I use a slightly different approach. I have a public boolean, bDebugMode, and whenever I need to debug something I set it to true using the Immediate Pane.

When I enable error handling I use:

If Not bDebugMode then On Error Goto Err_Handler

Your approach does the same basicly.

[NeoPa]

Interesting comment. I suppose such a sub-discussion can be considered a relevant part of the thread. In reality, I tend to comment out the line in a particular procedure if I need to disable error chacking for it, but another approach, similar to yours Smiley, would be to use a conditional compiler constant and to check that within the code stream. This can effect many blocks of code, and be enabled/disabled with a single comment character.

An illustrative example follows :

At the top of the module

Option Explicit
Option Compare Database
 
#Const conDebug = True     'Only when the project is still in development mode.

Wherever you want code to exist only when in Debug mode

#If conDebug Then
    On Error GoTo Err_CurrentProcName
#End If

Although I don't generally use this concept for this specific purpose, I use it quite heavily otherwise. In spreadsheets I only protect worksheets in the released project for instance.

[Adam Tippelt]

Some of it sounds familiar to what I have been doing to get round things like handled errors in debug mode, so at least I'm doing some of the right things!

Thanks for all the information - can never know enough. :)