Obtaining the failing Line Of Code (LOC)

[mdlueck]

I would like to provide my error handler with one further capability: Retrieve / display / log the failed LOC. I have the handler providing context sensitive details about the error, but for long subs/functions I think there is the possibility to not be sure a to which LOC caused the error.

Other interpretive languages provide a sourceline capability of fetching the original LOC which failed. I have not seen such in VBA yet. Having such would at least record the exact LOC which caused the error. Suggestions?

 

[DJkarl]

Well you can do this, if you number each of your lines yourself.

Sub testline()
On Error GoTo errH
1:
2:
3: err.Raise 5001, , "Test Error"
4:
5:
6:
7:
Exit Sub
errH:
Debug.Print err.Number & err.Description & ":" & Erl
End Sub

 

[pbaldy]

Google a great free tool called MZ Tools that will add line numbers for you. I haven't used that feature, but I know others who have.

 

[mdlueck]

I would like to avoid line numbers like the plague GW BASIC!

But yes, at first glance that is the type of capability I would like to incorporate.

Any non line number Rx's?

 

[Banana]

This is not the exact same thing but in my humble opinion more than good enough:

On Error GoTo ErrHandler

...

ExitProc:
  Exit <procedure>
ErrHandler:
  MsgBox Err.Number & ", " & Err.Description
  Resume ExitProc
  Resume

When I get a messagebox with an error, I just need to use Ctrl + Break, then set the next execution to "Resume" (it's unreachable where it is so it'll never be hit in normal use) which takes me to the offending statement.

Since your error handling already reports procedure name, you should be able to re-run the procedure and get the error & break and use that Resume to put you back.


An alternative is if you're willing to pay is Wayne Philips' vbWatchDog @ EverythingAccess.com

 

[mdlueck]

When I get a messagebox with an error, I just need to use Ctrl + Break, then set the next execution to "Resume" (it's unreachable where it is so it'll never be hit in normal use) which takes me to the offending statement.

I am puzzled at what you mean by this. I am not aware of any option to jump into the source code at run-time.

Attached is a sample error box, such as I have developed presently.

This error happened to be that I defined a function to return As Object rather than As Variant. Since that function was only a single LOC I declined to do the proper error handling in the function getADODBConnectionObj() which sort of threw me a curve ball.

 

[Banana]

Have you ever stepped through code before? This is essentially what is being done when using the unreachable Resume trick.

 

[mdlueck]

I was able to produce what you described, and it works even without the unreachable resume.

Perhaps as I have a global function do handle the creation of the errorlog msgbox, there is much code to execute that it does not reach the point of the failure when tracing immediately.

So, thanks for the education that MsgBox's may be ctrl-break aborted.

 

[Banana]

How exactly did you get it to work without the unreachable Resume? When you ctrl+break, you are taken to the line right after the MsgBox and if it's in an error handler, you'd need to use the Resume to return you to the actual line that failed.

 

[mdlueck]

I have the msgbox call in my shared errorhandler area. Like I said, the errorhandler is rather involved. After it displays the MsgBox, it then logs the same error information to a text file application error log.

What I have scattered around in each method's error handler is a call to the centralized error handler including custom string information stating where the error came from. So one LOC in each method... I dislike verbosity in copy/paste!

Example:

Err_uiutils_SetMouseDefault:
  Call errorhandler_MsgBox("Module: modshared_uiutils, Function: uiutils_SetMouseDefault()")
  Resume Exit_uiutils_SetMouseDefault

End Sub