[Resolved] Error handling in class module

Friends,

Following is a method in one of my VB6.0 class that I intend to deploy as COM+ application. I have a phobia handling errors... I guess. Please comment on the simple error handling I have used. And any suggestions/advise is highly appreciated.
Thanks in advance!

"RaiseError" is a sub that simply does

VB Code:

err.raise eNo, eSrc, eDesc

VB Code:

Public Function GetCustomClients(ByVal bRegClient As Boolean) As ADODB.Recordset
 
  '==================================================
  '  Parameters In: Boolean flag; True for regular clients
  '  Returns      : Recordset containing - Client-Id, Client-Name
  '                 and Description
  '  Description  : Used to build the User-Interface (list-box)
  '==================================================
 
  On Error GoTo errHandler
  
  Dim cClient As New ADODB.Command
  Dim pFlg As ADODB.Parameter
  
  eNo = 0                   'declared form-level
  eDesc = vbNullString                                   'form-level
  eSrc = "GetCustomClients"                           'form-level
  
  cClient.ActiveConnection = ConnStr
  cClient.CommandType = adCmdStoredProc
  cClient.CommandText = "qryCustomClients"
 
  Set pFlg = cClient.CreateParameter("bFlg", adBoolean, adParamInput, , bRegClient)
  cClient.Parameters.Append pFlg
  
  Set GetCustomClients = cClient.Execute()
 
errExit:
  Exit Function
 
errHandler:
  If Err.Number > 0 Then
    eNo = Err.Number
    eDesc = Err.Description
    Err.Clear
    On Error GoTo 0
    Call RaiseError
  End If
End Function

I personally would do something like this:

VB Code:

Option Explicit
 
Public Function GetCustomClients(ByVal bRegClient As Boolean) As ADODB.Recordset
10        On Error GoTo errHandler
          Dim cClient As New ADODB.Command, pFlg As ADODB.Parameter
20        eNo = 0:  eDesc = vbNullString:  eSrc = "GetCustomClients"
30        cClient.ActiveConnection = ConnStr
40        cClient.CommandType = adCmdStoredProc
50        cClient.CommandText = "qryCustomClients"
60        Set pFlg = cClient.CreateParameter("bFlg", adBoolean, adParamInput, , bRegClient)
70        cClient.Parameters.Append pFlg
80        Set GetCustomClients = cClient.Execute()
          
90        Exit Function
          
errHandler:
100       HandleError Err
End Function
 
Public Sub HandleError(ByRef Err As ErrObject)
    Dim strErrorPrompt As String
    strErrorPrompt = "Error Number: %num%" & vbCrLf & "Error Desc: %desc%" & vbCrLf & "On Line: %erl%"
    strErrorPrompt = Replace(strErrorPrompt, "%num%", Err.Number)
    strErrorPrompt = Replace(strErrorPrompt, "%desc%", Err.Description)
    strErrorPrompt = Replace(strErrorPrompt, "%erl%", Erl)
    
    LogToFile (Err.Number & vbCrLf & Err.Description & vbCrLf & Erl)
    ''
    '' or
    ''
    LogToEventViewer (Err.Number & vbCrLf & Err.Description & vbCrLf & Erl)
    ''
    '' or
    ''
    LogToDB (Err.Number & vbCrLf & Err.Description & vbCrLf & Erl)
End Sub

Thanks much, plenderj! I heartly appreciate it.

since it is a class I wanted to raise error to the calling application, is that okay?

I like your idea of having a central method like "HandleError". Would it be a good idea to make it dll. May be add some error constants to it too.
(But somewhere on this forum I read that a general method to handle error isn't advisible).

Thanks!

Quote:

---

Originally Posted by vbXML

Thanks much, plenderj! I heartly appreciate it.

since it is a class I wanted to raise error to the calling application, is that okay?

---

Yes.

Quote:

---

Originally Posted by vbXML

I like your idea of having a central method like "HandleError". Would it be a good idea to make it dll. May be add some error constants to it too.

---

If you are going to use this in multiple applications, then again, I would say 'yes'.

Quote:

---

Originally Posted by vbXML

(But somewhere on this forum I read that a general method to handle error isn't advisible).

---

A general method is just that, a GENERAL method. It would handle your garden variety type of errors, but such a practice is discouraged because you still wind up having to deal with errors that are specific to the way your code is written. Unless you want to spend the time writting a .Dll that will cover every single possible error that could ever occur in an application, you will always need specific error trapping written in.

Of course, your .Dll could just be general. In other words, regardless of what the error is, you could just write it off to something and have the program continue. This would ensure that your program wouldn't bomb on a runtime error, but it probably wouldn't be very useful in attempting to determine what happened and why it happened.

Thank you much for the detailed explaination, Hack! Thats huge!