I have VB6 application , I want to put some good error handling finction in it which can tell me what was the error and exact place when it happened , can anyone suggest the good way to do this
First of all, go get MZTools for Visual Basic 6, its free and invaluable. Second add a custom error handler on every function (yes, every function). The error handler we use looks something like this:
On Error GoTo {PROCEDURE_NAME}_Error
{PROCEDURE_BODY}
On Error GoTo 0
Exit {PROCEDURE_TYPE}
{PROCEDURE_NAME}_Error:
LogError "Error " & Err.Number & " (" & Err.Description & ") in line " & Erl & _
", in procedure {PROCEDURE_NAME} of {MODULE_TYPE} {MODULE_NAME}"
Then create a LogError function that logs the error to disc. Next, before you release code add Line Numbers to every function (this is also built into MZTools). From now on you will know from the Error Logs everything that happens. If possible, also, upload the error logs and actually examine them live from the field.
This is about the best you can do for unexpected global error handling in VB6 (one of its many defects), and really this should only be used to find unexpected errors. If you know that if there is the possibility of an error occurring in a certain situation, you should catch that particular error and handle for it. If you know that an error occurring in a certain section is going to cause instability (File IO, Memory Issues, etc) warn the user and know that you are in an "unknown state" and that "bad things" are probably going happen. Obviously use friendly terms to keep the user informed, but not frightened.
a simple way without additional modules, useful for class modules:
pre-empt each function/subs:
On Error Goto Handler
handler/bubbleup:
Handler:
Err.Raise Err.Number, "(function_name)->" & Err.source, Err.Description
voila, ghetto stack trace.
I use a home-grown Error.bas module to make reporting and re-raising less cumbersome.
Here's its contents (edited for length):
Option Explicit
Public Sub ReportFrom(Source As Variant, Optional Procedure As String)
If Err.Number Then
'Backup Error Contents'
Dim ErrNumber As Long: ErrNumber = Err.Number
Dim ErrSource As String: ErrSource = Err.Source
Dim ErrDescription As String: ErrDescription = Err.Description
Dim ErrHelpFile As String: ErrHelpFile = Err.HelpFile
Dim ErrHelpContext As Long: ErrHelpContext = Err.HelpContext
Dim ErrLastDllError As Long: ErrLastDllError = Err.LastDllError
On Error Resume Next
'Retrieve Source Name'
Dim SourceName As String
If VarType(Source) = vbObject Then
SourceName = TypeName(Source)
Else
SourceName = CStr(Source)
End If
If LenB(Procedure) Then
SourceName = SourceName & "." & Procedure
End If
Err.Clear
'Do your normal error reporting including logging, etc'
MsgBox "Error " & CStr(ErrNumber) & vbLf & "Source: " & ErrSource & vbCrLf & "Procedure: " & SourceName & vbLf & "Description: " & ErrDescription & vbLf & "Last DLL Error: " & Hex$(ErrLastDllError)
'Report failure in logging'
If Err.Number Then
MsgBox "Additionally, the error failed to be logged properly"
Err.Clear
End If
End If
End Sub
Public Sub Reraise(Optional ByVal NewSource As String)
If LenB(NewSource) Then
NewSource = NewSource & " -> " & Err.Source
Else
NewSource = Err.Source
End If
Err.Raise Err.Number, NewSource, Err.Description, Err.HelpFile, Err.HelpContext
End Sub
Reporting an error is as simple as:
Public Sub Form_Load()
On Error Goto HError
MsgBox 1/0
Exit Sub
HError:
Error.ReportFrom Me, "Form_Load"
End Sub
Reraising an error is as simple as calling Error.Reraise with the new source.
Although it is possible to retrieve the Source and Procedure parameters from the call stack if you compile with symbolic debug info, it's not reliable enough to use in production applications
ON ERROR GOTO
and the
Err
object.
There is a tutorial here.
Yes, take Kris's advice and get MZTools.
You can add line numbers to section off areas of complex procedures, which ERL will report in the error handler, to track down which area is causing the error.
10
...group of statements
20
...group of statements
30
...and so on
Use on
dim errhndl as string
on error goto errhndl
errhndl:
msgbox "Error"
Use the On Error statement and the Err object.
Related
I have written an error handling sub in my vb script
errorNumber = DoAllWork
Sub ErrorHandling (Number, Description, i)
If Number <> 0 Then
WriteLogFileLine logfile, "Error No : " & Number & " - " & Description & " has occurred !"
Else
WriteLogFileLine logfile, "Success copying files as Err.Number : " & Err.Number & "Total " & i & " files were copied ! " & vbcrlf
End If
Err.Clear
End Sub
And I am calling it in my vb script like this
Function DoAllWork
On Error Resume Next
Err.Clear
Do Until CopyFiles.AtEndOfStream
line = CopyFiles.ReadLine
For Each line In CopyFiles
If objFSO.GetFolder(line).Files.Count <> 0 then
WriteLogFileLine logfile, "Copying files FromLocation " & Chr(34) & line & Chr(34) & " to ToLocation " & Chr(34) & ToLocation & Chr(34)
Else
WriteLogFileLine logfile, "No files present in the folder " & Chr(34) & line & Chr(34) & vbcrlf
End if
i=0
For Each File In objFSO.GetFolder(line).Files
objFSO.GetFile(File).Copy ToLocation & "\" & objFSO.GetFileName(File),True
i=i+1
Next
ErrorHandling Err.Number, Err.Description, i
Next
Loop
End Function
Now the log file which is getting created has this error messages logged in it even though the files has got copied successfully. Can someone please suggest what is wrong with this error handling technique ??
2015-12-15 15:03:47 - Copying files FromLocation "\\srv10219\archive\Article\20151116_073104" to ToLocation "C:\Users\TEMPPAHIR\LearnVB\ICCdata\Article"
2015-12-15 15:03:47 - Error No : 438 - Object doesn't support this property or method has occurred !
when I place this error handling directly after the File.copy statement, it gives me such log..
2015-12-15 16:31:55 - Error No : 438 - Object doesn't support this property or method has occurred !
2015-12-15 16:31:55 - Success copying files as Err.Number : 0
2015-12-15 16:31:55 - Total 2 files were copied !
that means for the first file which is being copied it throws an error and for the second one it gives success even though both the files has been copied successfully
I implemented this to do pretty much what you asked. What the script needed to do was take a folder and its contents that was dropped into a directory, and then copy the contents to a new folder formatted correctly where there was a poller that picked up the files and entered them in our system. I needed the script to quit on any error, especially for the last thing to do. That was to delete the folder from the source directory, but I had to make sure it got copied correctly. (You could clear the error and continue as well.)
So after each important line like a folder create or a file copy I did this check. This worked for me to do error handling. Passing the Err object itself is the best way to go.
Set FolderCreate = FSO.CreateFolder(PreStagingDirectory + "\" + FolderCreateName)
ReportErrors Err,"Error creating folder: " + PreStagingDirectory + "\" + FolderCreateName
FSO.CopyFile objFile.Path, FolderCreate.Path + "\", true
ReportErrors Err,"Error copying file: " + objFile.Path + " to location: " + FolderCreate.Path
Sub ReportErrors(ErrorObject, strExtraInformation)
'This will log any errors if they happen and the script will then quit
If ErrorObject.Number <> 0 Then
OutPutFile.WriteLine(DateTimeString + " Error Number: " & ErrorObject.Number)
OutPutFile.WriteLine(DateTimeString + " Error (Hex): " & Hex(ErrorObject.Number))
OutPutFile.WriteLine(DateTimeString + " Source: " & ErrorObject.Source)
OutPutFile.WriteLine(DateTimeString + " Description: " & ErrorObject.Description)
OutPutFile.WriteLine(DateTimeString + " Other Information: " + strExtraInformation)
OutPutFile.WriteLine(DateTimeString + " Script is quitting due to the Error Condition.")
wscript.quit
End If
End Sub
I have also done code like this. In this case I needed to catch if null was returned from a SQL query to the database. If null was returned and I try to cast the value, it caused an error.
To answer the question of should you check for errors in a sub and clear them, or check for errors all through your script really depends what you need to accomplish.
First I have to say error handling in vbscipt just sucks. Using 'On Error Resume Next', is absolutely needed but be careful where you place it. I found it is not best to place it in main, at the top, just within each function. Most important is to remember the scope, if you put it in a function, you catch the error there, and can handle it. If you only have it at as the first line of your script, you can only handle an error in main. It is needed in main, sometimes.
Also to debug any vbscript, comment out any call to that, or you will never know the problem.
ExecutionString = "select Sum(cast(Frame_Count as int)) from Sop_Instance_T"
Set objRecordSet = objConnection.Execute(ExecutionString)
TotalFrames = cdbl(objRecordSet(0))
'In case null is returned catch the exception
'that happens on the above line
If Err.Number <> 0 Then
TotalFrames = 0
Err.Clear ()
End If
From some Visual Basic Script I accidentally tried to launch a program that did not exist:
Dim WshShell
Set WshShell = CreateObject("Wscript.Shell")
On Error Resume Next
WshShell.Run "incorrect"
WScript.Echo "Error:" & vbTab & Err.Description & vbCrLf & _
"Code:" & vbTab & Hex(Err.Number)
That gives:
Error:
Code: 80070002
So no description.
When I disable error checking (comment out the On Error Resume Next), I do get a description:
---------------------------
Windows Script Host
---------------------------
Script: D:\Folder\MyScript.vbs
Line: 3
Char: 1
Error: The system cannot find the file specified.
Code: 80070002
Source: (null)
---------------------------
OK
---------------------------
Is this difference in behavior a bug? Or am I missing something? I cannot find this documented anywhere.
I've done some testing myself and it appears to only happen with WshShell.Run().
For example try the following code which will work the same way but note the output.
Dim WshShell
Set WshShell = CreateObject("WScript.Shell")
On Error Resume Next
'This line will fail because there is no Type of 88.
WshShell.LogEvent 88, "incorrect"
WScript.Echo "Error:" & vbTab & Err.Description & vbCrLf & _
"Code:" & vbTab & Hex(Err.Number)
Output (with On Error Resume Next):
Error: Invalid procedure call or argument
Code: 5
Output (without On Error Resume Next):
Error: Invalid procedure call or argument
Code: 5
My guess is that WshShell.Run() is only reading from StdOut and not StdErr when On Error Resume Next is used, this is unique to WshShell.Run() because it is attempting to create a new process.
You could take this further by perhaps testing using WshShell.Exec() which gives access to both output streams.
Dim WshShell
Set WshShell = CreateObject("WScript.Shell")
On Error Resume Next
Set WshExec = WshShell.Exec("incorrect")
WScript.Echo "Error:" & vbTab & Err.Description & vbCrLf & _
"Code:" & vbTab & Hex(Err.Number)
Weirdly checked both WshExec.StdOut and WshExec.StdErr and neither contain the error output but the method behaves as expected when On Error Resume Next is used.
So not by any means conclusive.
But as the accompanying article states;
Just remember, scripting without mysteries would be insipid and boring
Useful Links
Doctor Scripto's Script Shop: To Err Is VBScript – Part 1
Is theres a way to hide a vb6 error? I have a program that prompt an error but everything goes fine. Any help will be highly appreciated. Thanks.
UPD the code:
Set WshShell = CreateObject("WScript.Shell") 'passing the values to program2
strCommand = """" & App.Path & "\Prog2.exe """ & strArgs(0) & ";" & Trim$(.cFileName) & ";" & strArgs(1) WshShell.Run strCommand
you may suppress exception raising in vb in the following way:
on error resume next
doSomeDangerousStuff
if err.Number <> 0 then
'here is some optional error handling code
MsgBox "Exception occured: " & Err.Description
end if
on error goto 0
after the declaration of your function/sub put
on error goto error_filter
'your code is here'
before the ending of your sub/function put this
error_filter:
if err.description = (the error description you want to eliminate) then
exit sub
end if
I developed an application in VB6. In client's environment it raises runtime errors which I can't reproduce under debugger. Is there any way to get the stacktrace or location of error?
I created log file and
I used
Err.Description,Err.Source
but it gives blank values.
Please help me.
my method(......
On Error GoTo Error_Handler
.........
Error_Handler :
writeToLogFile(Err.Source,Err.Description)
You've probably done something to clear the Err object before writing to the log file. This is very, very easy to do. What you'll want to do is as soon as you detect an error has occurred, grab the error message before doing anything else. Then pass the error message to whatever logging routine you're using. E.g.:
Dim sMsg As String
On Error Goto ErrHandler
' ...code here...
Exit Function
ErrHandler:
sMsg = "Error #" & Err.Number & ": '" & Err.Description & "' from '" & Err.Source & "'"
GoLogTheError sMsg
BTW, thanks for your guys' answers helping me. I'm about half a decade late to the game of VB6. I don't do windows unless forced to. ;)
Anyhow, when doing your error checking, say among 3000 individual record query insertions, I learned a couple tricks. Consider this block of code:
'----- order number 1246-------
On Error Goto EH1246:
sSql="insert into SalesReceiptLine ( CustomerRefListID,TemplateRe..."
oConnection.Execute sSQL
sSql="SELECT TxnID FROM SalesReceiptLine WHERE RefNumber='1246'..."
oRecordset.Open sSQL, oConnection
sTxnId = oRecordset(0)
oRecordset.Close
sSql="INSERT INTO SalesReceiptLine (TxnId,SalesReceiptLineDesc,Sal..."
oConnection.Execute sSQL
EH1246:
IF Err.Number<>0 THEN
sMsg = sMsg & "Order # 1246; sTxnId = " & sTxnId & _
vbCrLf & Err.Number & ": " & Err.Description & vbCrLf
sErrOrders = sErrOrders & "1246,"
End If
On Error GoTo -1
'----- order number 1247-------
On Error Goto EH1247:
When not testing for Err.Number, you'll get a 0: on every order handled. (maybe you don't want that). The On Error GoTo -1 resets the error so that it will work again. Apparently, Err only works "once".
I wrote a php script to build the VB6 source code to run some 8000 odbc queries... :P
Do you definitely, positively have an Exit Function just above the Error_Handler:?
my method(......
On Error GoTo Error_Handler
........
Exit Sub
Error_Handler :
writeToLogFile(Err.Source,Err.Description)
"Exit Sub" should be added before you handle the Error_Handler function.....
I am changing document template macros. The one thing I can't find out how to do is to customize error messages. For example an error message in a document is
"Error! No table of figures entries found"
I would like to change this to display something else. Is it possible to do this with Word VBA or VBScript?
Is it possible to put this in some
kind of global error handler? – Craig
It is possible. Here is a very rough example.
In a standard module:
Sub HandleErr(ErrNo As Long)
Select Case ErrNo
Case vbObjectError + 1024
MsgBox "No table of figures entries found.", vbOKOnly + vbCritical
Case vbObjectError + 1034 To vbObjectError + 4999
MsgBox "Still no table of figures entries found.", vbOKOnly + vbCritical
Case Else
MsgBox "I give up.", vbOKOnly + vbCritical, _
"Application Error"
End Select
End Sub
Some code:
Sub ShowError()
Dim i As Integer
On Error GoTo Proc_Err
'VBA Error
i = "a"
'Custom error
If Dir("C:\Docs\TableFigs.txt") = "" Then
Err.Raise vbObjectError + 1024
End If
Exit_Here:
Exit Sub
Proc_Err:
If Err.Number > vbObjectError And Err.Number < vbObjectError + 9999 Then
HandleErr Err.Number
Else
MsgBox Err.Description
End If
End Sub
If you want to trap a specific error type in VBA, one method is to use On Error Resume Next then test for an error message on the line following the action to trap, e.g.:
On Error Resume Next
' try action
If Err.Number <> 0 Then
' handle w/ custom message
Err.Clear
End If
If you know the exact error number (If Err.Number = N Then), that would be better of course.
Well if you are talking about having a custom message box - that's easy.
Look up 'msgbox' in VBA help for better info.
Msgbox("Error! No table of figures entries found",16,"Error")
The 16 makes it a 'criticial' message.
If you're talking about error trapping then you'll need code like this:
On Error Resume Next
n = 1 / 0 ' this causes an error
If Err.Number <> 0 Then
n = 1
if Err.Number = 1 Then MsgBox Err.Description
End If
When an error is thrown, a number and description are given to the Err object.