Trying to improve my error handling and the information that the message provides

[Seth Schrock]

I found out that VB.net has a function that tells you the last line that executed properly. It is something like Err.LastLineExe cuted (its close anyway). However, this isn't available in Access VBA. I would like to possibly create something close to it. What I had in mind was to group my code and after the group executes successfully, then mark it as such. Something like this:

On Error GoTo Procedure_Error

Dim intLastGroup as Integer
intLastGroup = 0
'Set to 0 at the beginning of the function/sub

'first set of code
intLastGroup = 1

'more code in second group
intLastGroup = 2

Procedure_Exit:
    Exit Sub

Procedure_Error:
    MsgBox "Error Number: " & Err.Number & _
           VbCrLf & "Description: " & Err.Description & _
           VbCrLf & "Error in group: " & intLastGroup + 1 & _
           VbCrLf & "Module: [I]module_name[/I]"
    Resume Procedure_Exit

My thinking is that if the error happens in the first group of code, then it won't have reached line 8, intLastGroup will still equal 0 and my error message will post Error in group: 1. Does this seem like a good idea or does it add overhead that would slow everything down? Is there another way to get the same effect that would work better?

[NeoPa]

It should work fine Seth.

However, and it's a big however to my mind, it will add more code to maintain. That said, if it's just a sequence of numbers and it isn't updated when it should be then it can still prove useful as long as you have the correct source code to work with when analysing the error report from a user.

In that respect it's probably less of a maintenance problem than developer comments that don't keep up with all the amendments over time. They can be positively misleading and waste you lots of time. The rule there is "If you have comments in your code then keeping them relevant is as important as updating the code itself."

[Seth Schrock]

The nice thing is that the numbers don't mean anything to the code so changes to the code just changes the amount of code in each group. However, to make it easier to change the groups I might use the following code:

intLastGroup = intLastGroup + 1

This way, if I decide to break up a group into two groups, I don't have to re-number all the groups that come after. This will make it easier to keep it up to date.

Thanks for your insight NeoPa.

[NeoPa]

Seth:
The nice thing is that the numbers don't mean anything to the code so changes to the code just changes the amount of code in each group

That expresses my later thoughts exactly Seth :-) Less of a problem than comments in code. Your idea for using X=X+1 is clever, but may (possibly) lead to more problems than it solves. It will probably help more to have the actual value to expect to see associated with each block of code when you're checking through it.

[Seth Schrock]

I'm actually in the process of discovering that NeoPa. The biggest issue is when you run into an If/Then statement. Using just the X=X+1 means you don't know where you are unless you know which path it took you on. Loops could also cause problems, but most of the time I would think that I would be able to just put it at the end and outside of the loop.

[NeoPa]

Seth:
but most of the time I would think that I would be able to just put it at the end and outside of the loop.

Don't be afraid to let go of clever ideas Seth. It was clever - but doesn't suit this problem well. Revert to X=1; X=2; etc. Why give yourself headaches?

[Seth Schrock]

That is my plan. After working through If/Then statements, I'm also wondering about putting my flags at the beginning of the groups instead of at the end. This would make it easier to track my way through the path that the code was executed. My problem is that most of my users are using Access Run-time and errors just cause the database to close without the option to debug. The default error messages just state that there was a problem and the application must close. So, I'm trying to use my error trapping to be a good alternative to the debug feature that the regular Access error message provides.

I'll play around with it some more and let you know what I come up with.