Prev: locking out part of code in VB6
Next: Read and Parse Emails using VB
From: David on 26 Mar 2010 22:34
I have a central error routine and decided to make some improvements
for User Defined Errors.

Currently I use Err.Raise (for User Defined Errors) in a local procedure and
then pass the Error Description for that error from the local procedure to
my central error routine.

I thought it would be nice to centralize all User Defined Error Descriptions
in the central error routine.

I set up the following function:

Private Function GetUserDefinedError(ByVal lngUserErrorNo As Long) As String

Dim strReturn As String

Select Case lngUserErrorNo

'General Errors
Case ERR_NUMBER_OUTRANGE
strReturn = "NUMBER_OUTRANGE"
Case ERR_INVALID_DATE
strReturn = "INVALID_DATE"

End Select


'*******
'WRAPUP
'*******
GetUserDefinedError = strReturn

End Function

==============

Where I'm having issues is screening for User Errors versus System Errors in
the calling procedure and do it in "one" call.
What I had in mind was something like:

If Len(GetUserDefinedError( Err.Number )) >0 then
'Show User Error
Else
'Show System Error
End If

I can do it in two by having another procedure return a boolean if it is a
user defined error and then call "GetUserDefinedError" to get the User Error
Description.

Two thoughts came to mind (VB5):
1) Return a boolean from the called proc and also pass the string
(description) back as a parameter from the called routine.

2) Set up a "private" structure to hold the returns (# and description) and
then evaluate this structure.

Looking for feedback or a better idea?







From: mscir on 27 Mar 2010 01:25
On 3/26/2010 7:34 PM, David wrote:
> I have a central error routine and decided to make some improvements
> for User Defined Errors.
>
> Currently I use Err.Raise (for User Defined Errors) in a local procedure and
> then pass the Error Description for that error from the local procedure to
> my central error routine.
>
> I thought it would be nice to centralize all User Defined Error Descriptions
> in the central error routine.
>
> I set up the following function:
>
> Private Function GetUserDefinedError(ByVal lngUserErrorNo As Long) As String
>
> Dim strReturn As String
>
> Select Case lngUserErrorNo
>
> 'General Errors
> Case ERR_NUMBER_OUTRANGE
> strReturn = "NUMBER_OUTRANGE"
> Case ERR_INVALID_DATE
> strReturn = "INVALID_DATE"
>
> End Select
>
>
> '*******
> 'WRAPUP
> '*******
> GetUserDefinedError = strReturn
>
> End Function
>
> ==============
>
> Where I'm having issues is screening for User Errors versus System Errors in
> the calling procedure and do it in "one" call.
> What I had in mind was something like:
>
> If Len(GetUserDefinedError( Err.Number ))>0 then
> 'Show User Error
> Else
> 'Show System Error
> End If
>
> I can do it in two by having another procedure return a boolean if it is a
> user defined error and then call "GetUserDefinedError" to get the User Error
> Description.
>
> Two thoughts came to mind (VB5):
> 1) Return a boolean from the called proc and also pass the string
> (description) back as a parameter from the called routine.
>
> 2) Set up a "private" structure to hold the returns (# and description) and
> then evaluate this structure.
>
> Looking for feedback or a better idea?

I use this for all of my error trapping, and call it from every sub or
function:

Public Sub ErrHandler(loc As String, num As String, dscr As String)
MsgBox "There was an Error" & vbCrLf & vbCrLf & _
"Error Location " & loc & vbCrLf & _
"Error Number " & num & vbCrLf & _
"Description " & dscr & vbCrLf, vbOKOnly, "Error!"
End Sub

When called from this sub it works as expected:

Private Sub Command2_Click()
On Error GoTo command2err
Dim filenum As Long
filenum = 0
Open "somethingthatdoesntexist" For Input As #filenum
Close #filenum
Exit Sub
'
command2err:
ErrHandler "command2", Err.Number, Err.Description
End Sub

When used in the sub below the description field includes the following
text, without the quotes:

"Application-defined or object-defined error"

Private Sub Command1_Click()
On Error GoTo command1err
Err.Raise 33
Exit Sub
'
command1err:
ErrHandler "command1", Err.Number, Err.Description
End Sub

The messagebox looks like this:

There was an Error
Error Location command1
Error Number 33
Description Application-defined or object-defined error

This is VB6, maybe VB5 will do something similar that you can test for.

Mike




--- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---
From: Larry Serflaten on 27 Mar 2010 09:11

"David" <NoWhere(a)earthlink.net> wrote

> Where I'm having issues is screening for User Errors versus System Errors in
> the calling procedure and do it in "one" call.

What is the issue with system errors vs user errors? It seems to me you only
need to know the description when you plan to show it or log it somewhere.

Could you not just add vbObjectError (or some other suitable value) to errors
caused by the user and then test the Err.Number to determine if you should
show the description from the Err object or call one up from your own list?

LFS


From: Nobody on 27 Mar 2010 08:27
"David" <NoWhere(a)earthlink.net> wrote in message
news:ONYAFYVzKHA.264(a)TK2MSFTNGP05.phx.gbl...
> Currently I use Err.Raise (for User Defined Errors) in a local procedure
> and then pass the Error Description for that error from the local
> procedure to my central error routine.

You need to specify "Source" parameter in Err.Raise to tell an error handler
it's your own error code. Also, rather than making a routine to return
Strings, which requires memory allocation and could be a problem in low
memory conditions, put these in an array in BAS module, and fill them at
application startup. That way they are always in memory.

Also, rather than defining your own errors As Long, try using Enum, so you
get Intellisense, and when you declare a function as this Enum, VB would
show the list of Enum values when you type the function name followed by "="
sign. Example:

Public Enum enumMyErrors
errSuccess
errUnknown
errNumOutOfRange
errInvalidDate
' ....
End Enum

Public sMyErrors(0 To 100) As String

Public Sub InitMyErrors()
sMyErrors(0) = "Success"
sMyErrors(1) = "Unknown"
sMyErrors(2) = "Number is out of range"
sMyErrors(3) = "Invalid date"
End Sub



From: David on 27 Mar 2010 09:02
Thanks for input guys.

Mr Serflaten:

Regarding:
-------------------------
Could you not just add vbObjectError (or some other suitable value) to
errors
> caused by the user and then test the Err.Number to determine if you should
> show the description from the Err object or call one up from your own
> list?
-------------------------

That's what I'm doing here.
Must of been "brain dead" last night -- I believe simple solution is:

In local procedure
1) Err.Raise <my constant> (Nobody don't believe Enum will work here -
will test)
2) Call DoError (Err.Number param not needed since global)

In Error Module:

strMyError = GetUserDefinedError() '<< Err.Number global no param
needed
If Len(strMyError) > 0 Then
Msgbox, log or whatever
Else '<< system error
'Msgbox, log or whatever
End If





"Larry Serflaten" <serflaten(a)usinternet.com> wrote in message
news:u8DV6ZazKHA.4492(a)TK2MSFTNGP05.phx.gbl...
>
> "David" <NoWhere(a)earthlink.net> wrote
>
>> Where I'm having issues is screening for User Errors versus System Errors
>> in
>> the calling procedure and do it in "one" call.
>
> What is the issue with system errors vs user errors? It seems to me you
> only
> need to know the description when you plan to show it or log it somewhere.
>
> Could you not just add vbObjectError (or some other suitable value) to
> errors
> caused by the user and then test the Err.Number to determine if you should
> show the description from the Err object or call one up from your own
> list?
>
> LFS
>
>


 |  Next  |  Last
Pages: 1 2
Prev: locking out part of code in VB6
Next: Read and Parse Emails using VB