|
code
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
What line does the error start on?Dear All
If I have 2 subs, which for convenience I will call SubA and SubB: {} Both Subs use line numbers. {} SubA calls SubB 3 times with different values. {} An error is raised in SubB and error trapping using Erl gives me the line where the error is raised in SubB. How can I identify the line in SubA that calls SubB which results in the error, since SubB is called by SubA 3 times? Thanks again. Alastair MacFarlane Have an error handler in Sub A?
RBS Show quoteHide quote "Alastair MacFarlane" <anonym***@microsoft.com> wrote in message news:ed9QmQhQGHA.5116@TK2MSFTNGP10.phx.gbl... > Dear All > > If I have 2 subs, which for convenience I will call SubA and SubB: > > {} Both Subs use line numbers. > {} SubA calls SubB 3 times with different values. > {} An error is raised in SubB and error trapping using Erl gives me the > line where the error is raised in SubB. > > How can I identify the line in SubA that calls SubB which results in the > error, since SubB is called by SubA 3 times? > > Thanks again. > > Alastair MacFarlane > On Tue, 7 Mar 2006 18:22:37 -0000, "Alastair MacFarlane"
<anonym***@microsoft.com> wrote: Show quoteHide quote >Dear All Have the debug toolbar visible and use the "stack" trace. It's the> >If I have 2 subs, which for convenience I will call SubA and SubB: > >{} Both Subs use line numbers. >{} SubA calls SubB 3 times with different values. >{} An error is raised in SubB and error trapping using Erl gives me the line >where the error is raised in SubB. > >How can I identify the line in SubA that calls SubB which results in the >error, since SubB is called by SubA 3 times? > >Thanks again. > >Alastair MacFarlane last icon on the right, it looks like a stack of frames. That way you can jump into a previous call and see where the error might be. Then put a breakpoint there and step through the code. Long but worth it. ********************************************************************** Richm***@sympatico.ca Dog thinks: they feed me, they take care of me: they are gods. Cat thinks: they feed me, they take care of me: I am god. http://www3.sympatico.ca/richmann/ http://www.geocities.com/richmannsoft/ ********************************************************************** "Alastair MacFarlane" <anonym***@microsoft.com> wrote in message Programatically or while manually debugging in the IDE? Programmatically news:ed9QmQhQGHA.5116@TK2MSFTNGP10.phx.gbl... > If I have 2 subs, which for convenience I will call SubA and SubB: > > {} Both Subs use line numbers. > {} SubA calls SubB 3 times with different values. > {} An error is raised in SubB and error trapping using Erl gives me the > line where the error is raised in SubB. > > How can I identify the line in SubA that calls SubB which results in the > error, since SubB is called by SubA 3 times? you'd either have to use a variable for tracking purposes or an error handler and then raise an error from SubB. In the IDE, just hit the Call Stack button and then go into SubA. The calling line will have a green arrow. Thanks Jeff and Others,
I am thinking about end user and most importantly me debugging errors. If you raise an error from SubB you would only be able to return the Erl of SubB. To get the original calling line, the only way I can think of it is to declare a variable and set the value to be the line you are currently at. Am I correct in thinking that this would need to be done at every line? This would be too much work. Your continued help is appreciated. Alastair MacFarlane Show quoteHide quote "Jeff Johnson [MVP: VB]" <i.get@enough.spam> wrote in message news:unZ9mHiQGHA.1264@TK2MSFTNGP10.phx.gbl... > > "Alastair MacFarlane" <anonym***@microsoft.com> wrote in message > news:ed9QmQhQGHA.5116@TK2MSFTNGP10.phx.gbl... > >> If I have 2 subs, which for convenience I will call SubA and SubB: >> >> {} Both Subs use line numbers. >> {} SubA calls SubB 3 times with different values. >> {} An error is raised in SubB and error trapping using Erl gives me the >> line where the error is raised in SubB. >> >> How can I identify the line in SubA that calls SubB which results in the >> error, since SubB is called by SubA 3 times? > > Programatically or while manually debugging in the IDE? Programmatically > you'd either have to use a variable for tracking purposes or an error > handler and then raise an error from SubB. In the IDE, just hit the Call > Stack button and then go into SubA. The calling line will have a green > arrow. > "Alastair MacFarlane" <anonym***@microsoft.com> wrote in message Another way is to add an optional argument to SubB that accepts info you'd news:uCcsUQiQGHA.1676@TK2MSFTNGP14.phx.gbl... > Thanks Jeff and Others, > > I am thinking about end user and most importantly me debugging errors. If > you raise an error from SubB you would only be able to return the Erl of > SubB. To get the original calling line, the only way I can think of it is > to declare a variable and set the value to be the line you are currently > at. Am I correct in thinking that this would need to be done at every > line? This would be too much work. need to debug the routine. '================== Option Explicit Private Sub Command1_Click() Call SubB(2, 1) 'passes optional debug switch Call SubB(2, 2) 'the line below will raise an error. Since the 'DebugSwitch' is 3, 'finding the line that caused the sub to raise an error is easy Call SubB(0, 3) 'Once everything's debugged, you can optionally remove the second 'argument everywhere. End Sub Private Sub SubB(ByVal SomeInt As Integer _ , Optional ByVal DebugSwitch As Integer = 0) On Error GoTo ErrorTrap Dim sErrText As String 10 MsgBox 10 / SomeInt Terminate: Exit Sub ErrorTrap: sErrText = "Error " & Err.Number & " in SubB, Line: " & Erl _ & vbCrLf & Err.Description & vbCrLf 'Optionally break down and add to the message Select Case DebugSwitch Case 1 sErrText = sErrText & "Caller set DebugSwitch = 1" Case 2 sErrText = sErrText & "Caller set DebugSwitch = 2" Case 3 sErrText = sErrText & "Caller set DebugSwitch = 3" Case Else sErrText = sErrText _ & "DebugSwitch setting not supported or may not have been passed." End Select MsgBox sErrText Resume Terminate End Sub '================== -- Ken Halter - MS-MVP-VB - Please keep all discussions in the groups.. DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm As a small extra note: If you need to (rapidly) develop good-quality
error-handling code: http://www.urfinjus.net/UJv3/prodvb6/hunterr.aspx It works well for me, and I've used it extensively in real-world apps :) Robert Show quoteHide quote "Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.com> wrote in message news:%23RIxhZiQGHA.3972@TK2MSFTNGP10.phx.gbl... > "Alastair MacFarlane" <anonym***@microsoft.com> wrote in message > news:uCcsUQiQGHA.1676@TK2MSFTNGP14.phx.gbl... >> Thanks Jeff and Others, >> >> I am thinking about end user and most importantly me debugging errors. If >> you raise an error from SubB you would only be able to return the Erl of >> SubB. To get the original calling line, the only way I can think of it is >> to declare a variable and set the value to be the line you are currently >> at. Am I correct in thinking that this would need to be done at every >> line? This would be too much work. > > Another way is to add an optional argument to SubB that accepts info you'd > need to debug the routine. > '================== > Option Explicit > > Private Sub Command1_Click() > Call SubB(2, 1) 'passes optional debug switch > Call SubB(2, 2) > 'the line below will raise an error. Since the 'DebugSwitch' is 3, > 'finding the line that caused the sub to raise an error is easy > Call SubB(0, 3) > 'Once everything's debugged, you can optionally remove the second > 'argument everywhere. > End Sub > > Private Sub SubB(ByVal SomeInt As Integer _ > , Optional ByVal DebugSwitch As Integer = 0) > > On Error GoTo ErrorTrap > Dim sErrText As String > > 10 MsgBox 10 / SomeInt > > Terminate: > Exit Sub > > ErrorTrap: > sErrText = "Error " & Err.Number & " in SubB, Line: " & Erl _ > & vbCrLf & Err.Description & vbCrLf > 'Optionally break down and add to the message > Select Case DebugSwitch > Case 1 > sErrText = sErrText & "Caller set DebugSwitch = 1" > Case 2 > sErrText = sErrText & "Caller set DebugSwitch = 2" > Case 3 > sErrText = sErrText & "Caller set DebugSwitch = 3" > Case Else > sErrText = sErrText _ > & "DebugSwitch setting not supported or may not have been passed." > End Select > > MsgBox sErrText > Resume Terminate > > End Sub > '================== > > > > -- > Ken Halter - MS-MVP-VB - Please keep all discussions in the groups.. > DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm > Ken and others,
Thanks for the replies and Ken thanks for your code. Do you really think that the work involved in changing existing code and creating new code is worth the effort for even a relatively small application with a dozen forms. Is it possible to over-engineer error handling? Thanks again, Alastair MacFarlane Show quoteHide quote "Ken Halter" wrote: > "Alastair MacFarlane" <anonym***@microsoft.com> wrote in message > news:uCcsUQiQGHA.1676@TK2MSFTNGP14.phx.gbl... > > Thanks Jeff and Others, > > > > I am thinking about end user and most importantly me debugging errors. If > > you raise an error from SubB you would only be able to return the Erl of > > SubB. To get the original calling line, the only way I can think of it is > > to declare a variable and set the value to be the line you are currently > > at. Am I correct in thinking that this would need to be done at every > > line? This would be too much work. > > Another way is to add an optional argument to SubB that accepts info you'd > need to debug the routine. > '================== > Option Explicit > > Private Sub Command1_Click() > Call SubB(2, 1) 'passes optional debug switch > Call SubB(2, 2) > 'the line below will raise an error. Since the 'DebugSwitch' is 3, > 'finding the line that caused the sub to raise an error is easy > Call SubB(0, 3) > 'Once everything's debugged, you can optionally remove the second > 'argument everywhere. > End Sub > > Private Sub SubB(ByVal SomeInt As Integer _ > , Optional ByVal DebugSwitch As Integer = 0) > > On Error GoTo ErrorTrap > Dim sErrText As String > > 10 MsgBox 10 / SomeInt > > Terminate: > Exit Sub > > ErrorTrap: > sErrText = "Error " & Err.Number & " in SubB, Line: " & Erl _ > & vbCrLf & Err.Description & vbCrLf > 'Optionally break down and add to the message > Select Case DebugSwitch > Case 1 > sErrText = sErrText & "Caller set DebugSwitch = 1" > Case 2 > sErrText = sErrText & "Caller set DebugSwitch = 2" > Case 3 > sErrText = sErrText & "Caller set DebugSwitch = 3" > Case Else > sErrText = sErrText _ > & "DebugSwitch setting not supported or may not have been passed." > End Select > > MsgBox sErrText > Resume Terminate > > End Sub > '================== > > > > -- > Ken Halter - MS-MVP-VB - Please keep all discussions in the groups.. > DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm > > >
Show quote
Hide quote
"Alastair MacFarlane" <AlastairMacFarl***@discussions.microsoft.com> wrote For the "strange" errors, there's no way to over-engineer error handling. in message news:E8BA8322-AF20-4807-B489-0B08618BC7CB@microsoft.com... > Ken and others, > > Thanks for the replies and Ken thanks for your code. Do you really think > that the work involved in changing existing code and creating new code is > worth the effort for even a relatively small application with a dozen > forms. > > Is it possible to over-engineer error handling? > > Thanks again, > > Alastair MacFarlane For the trivial stuff that should be taken care of before deployment, a generic error trap should be good enough imo. That's just to trap the error so you can use Ctrl-L to see the call stack and check the contents of a few variables without VB unravelling itself. fwiw, I use CodeSMART and have a shortcut key that'll insert the following text into a procedure (I actually have a bunch of shortcut keys defined to do all kinds of things)... You'll note the Debug.Assert line that forces VB to stop if I get an error in the IDE. Also the seemingly useless Resume at the end. That's actually quite handy. When VB gets to the Debug.Assert line and stops, I select the Resume line, hit Ctrl-F9 so set the 'current instruction' then F8. That takes me back to the line that raised the error. '============================================================== Terminate: 'clean up code here Exit Sub ErrorTrap: MsgBox "Error " & Err.Number & vbCrLf & Err.Description Debug.Assert False 'Stops here in the IDE Resume Terminate Resume End Sub -- Ken Halter - MS-MVP-VB - Please keep all discussions in the groups.. DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm Ken,
Thanks for that. I appreciate your help and I know a colleague who swears by Codesmart as a product. I will need to look into it. Thanks. Alastair MacFarlane Show quoteHide quote "Ken Halter" wrote: > "Alastair MacFarlane" <AlastairMacFarl***@discussions.microsoft.com> wrote > in message news:E8BA8322-AF20-4807-B489-0B08618BC7CB@microsoft.com... > > Ken and others, > > > > Thanks for the replies and Ken thanks for your code. Do you really think > > that the work involved in changing existing code and creating new code is > > worth the effort for even a relatively small application with a dozen > > forms. > > > > Is it possible to over-engineer error handling? > > > > Thanks again, > > > > Alastair MacFarlane > > For the "strange" errors, there's no way to over-engineer error handling. > For the trivial stuff that should be taken care of before deployment, a > generic error trap should be good enough imo. That's just to trap the error > so you can use Ctrl-L to see the call stack and check the contents of a few > variables without VB unravelling itself. > > fwiw, I use CodeSMART and have a shortcut key that'll insert the following > text into a procedure (I actually have a bunch of shortcut keys defined to > do all kinds of things)... You'll note the Debug.Assert line that forces VB > to stop if I get an error in the IDE. Also the seemingly useless Resume at > the end. That's actually quite handy. When VB gets to the Debug.Assert line > and stops, I select the Resume line, hit Ctrl-F9 so set the 'current > instruction' then F8. That takes me back to the line that raised the error. > > '============================================================== > Terminate: > 'clean up code here > Exit Sub > > ErrorTrap: > MsgBox "Error " & Err.Number & vbCrLf & Err.Description > Debug.Assert False 'Stops here in the IDE > Resume Terminate > Resume > End Sub > > -- > Ken Halter - MS-MVP-VB - Please keep all discussions in the groups.. > DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm > > > Alastair,
> If I have 2 subs, which for convenience I will call SubA and SubB: How about making SubB a function and returning the line number in the > > {} Both Subs use line numbers. > {} SubA calls SubB 3 times with different values. > {} An error is raised in SubB and error trapping using Erl gives me the > line where the error is raised in SubB. > > How can I identify the line in SubA that calls SubB which results in the > error, since SubB is called by SubA 3 times? function value? Then in SubA you could do something like: A = SubB() If A <> 0 then MsgBox "Hit Error on line " & A Gary |
|||||||||||||||||||||||
Other interesting topics