Visual Basic - ErrHandling: FunctionTemplate

Author

ErrHandling: FunctionTemplate

Peter Plumber

2005-11-24, 6:55 pm

Hi,

our company is trying to establsh a coding standard for VB6
although it might be a little late :-(

as a result the following FunctionTemplate is possible
any comments?
any good arguments against,
and ideas how I could come with sth. better

btw.:
psUtil.registerError logs the error and returns an object
with the public error information

oCurrError.showError show a MsgBox if the errorr was not
shown until now

thx

Peter

----------------------------------------------------------

Private Function TemplateFunction( _
sParam As String, _
sParam2 As String, _
dStat As Double _
) As Long

Dim bThereWasAnError As Boolean

On Error GoTo Proc_Error
'-- begin individual code

'-- end individual code
Proc_Exit:

On Error Resume Next
'-- begin cleanup

'-- end cleanup

If bThereWasAnError Then
oCurrError.reraiseErr
Exit Function

Proc_Error:
Set oCurrError = psUtil.registerError(TypeName(Me) _
& ":TemplateFunction")
oCurrError.showError
bThereWasAnError = True
GoTo Proc_Exit

End Function

Jan Hyde

2005-11-24, 6:55 pm

Peter Plumber <Klempner@gmxdot.net>'s wild thoughts were
released on Thu, 24 Nov 2005 16:22:11 +0100 bearing the
following fruit:

>Hi,
>
>our company is trying to establsh a coding standard for VB6
>although it might be a little late :-(

Get MZTools version 3 (it's free) and set up all the
templates you like.

Personally I think your error code is over complicated.

J

>as a result the following FunctionTemplate is possible
>any comments?
>any good arguments against,
>and ideas how I could come with sth. better
>
>btw.:
>psUtil.registerError logs the error and returns an object
>with the public error information
>
>oCurrError.showError show a MsgBox if the errorr was not
>shown until now
>
>thx
>
>Peter
>
>----------------------------------------------------------
>
>
>Private Function TemplateFunction( _
> sParam As String, _
> sParam2 As String, _
> dStat As Double _
> ) As Long
>
> Dim bThereWasAnError As Boolean
>
> On Error GoTo Proc_Error
> '-- begin individual code
>
>
>
>
>
> '-- end individual code
>Proc_Exit:
>
> On Error Resume Next
> '-- begin cleanup
>
>
> '-- end cleanup
>
> If bThereWasAnError Then
> oCurrError.reraiseErr
> Exit Function
>
>Proc_Error:
> Set oCurrError = psUtil.registerError(TypeName(Me) _
> & ":TemplateFunction")
> oCurrError.showError
> bThereWasAnError = True
> GoTo Proc_Exit
>
>End Function

Jan Hyde (VB MVP)

--
Bruise: A six pack of beer (Kegel Archives)

[Abolish the TV Licence - http://www.tvlicensing.biz/]

Michael Cole

2005-11-24, 6:55 pm

Peter Plumber wrote:
> Hi,
>
> our company is trying to establsh a coding standard for VB6
> although it might be a little late :-(
>
> as a result the following FunctionTemplate is possible
> any comments?
> any good arguments against,
> and ideas how I could come with sth. better

Couple of thoughts: -

1. Second the MZTools advice - best addin that you can get.
2. Reraise errors up the call tree until you get to an event - and keep
track of the call stack as you go up. Then display the stack as information
for the error.
3. Using MZTools, you can write the template to also report the name of
the procedure
4. With a bit of extra code, you can also get and display the calling
parameters of the procedure.
5. Make sure that the error display mechanism can't get lost behind the
main form - pass the erroring form to the error display form to set as an
ownerform.

--
Regards,

Michael Cole

MikeD

2005-11-24, 6:55 pm

"Peter Plumber" <Klempner@gmxdot.net> wrote in message
news:eDMjYrQ8FHA.4084@TK2MSFTNGP10.phx.gbl...
> Hi,
>
> our company is trying to establsh a coding standard for VB6
> although it might be a little late :-(
>
> as a result the following FunctionTemplate is possible
> any comments?
> any good arguments against,
> and ideas how I could come with sth. better
>
> btw.:
> psUtil.registerError logs the error and returns an object
> with the public error information
>
> oCurrError.showError show a MsgBox if the errorr was not
> shown until now
>

I'm with Jan. I also think you've made your error handling much more
complicated that it needs to be. See remaining comments inline (note that
these are just my opinion).

>
> ----------------------------------------------------------
>
>
> Private Function TemplateFunction( _
> sParam As String, _
> sParam2 As String, _
> dStat As Double _
> ) As Long
>

This is just a personal preference, but I detest the parameter list being
split on multiple lines like that. I'm always asking myself "why is there
no damn Dim keyword?" and have to do a double-take. Annoys the hell out of
me. <g> I'm not implying there's anything wrong with it and I realize there
are many people that prefer the parameter list being on multiple lines. I'm
just not one of them as I don't like procedure headers being split into
several lines.

> Dim bThereWasAnError As Boolean

Why such a long variable name? Is not 'bError' just as clear? Shoot, even
'bErr' I'd think would be clear enough. You always want to use meaningful
variable names, but you don't want to get carried away with them either
(which IMO is just as bad as meaningless/vague variable names).

>
> On Error GoTo Proc_Error
> '-- begin individual code
>
>
>
>
>
> '-- end individual code
> Proc_Exit:
>
> On Error Resume Next

Why are you choosing to ignore errors here? If an error occurs in your
cleanup code, would you not want it handled by your normal error handler? I
would.

> '-- begin cleanup
>
>
> '-- end cleanup
>
> If bThereWasAnError Then
> oCurrError.reraiseErr
> Exit Function

You're missing an End If <g>

Also, I'm not sure why you're re-raising the error as it's already been
dealt with (logged and a messagebox shown to the user, which I'll get to in
a bit). Why do you need it additionally dealt with in another procedure? In
some cases, yes, you do want to trap an error and then re-raise it back to
the calling procedure (or whatever procedure in the call stack currently has
the active error handler), but doing so should not be the norm. It's
something you might do under special and specific circumstances. Not sure
what code you've got in your reraiseErr method, but this seems an awkward
way to exit the procedure. It just doesn't seem "clean" because, if I'm
understanding your code right, the Exit Function will never execute (nor
will you ever reach the End Function for the procedure) if an error had
occurred.

Error handling should be robust to deal with errors appropriately, but it
should also be as simple and straight-forward as possible. Think about it.
Who wants to spend hours figuring out error handling code because it's so
complex? Mainly, I think you're trying to do too much.

>
> Proc_Error:
> Set oCurrError = psUtil.registerError(TypeName(Me) _
> & ":TemplateFunction")
> oCurrError.showError

Unless you're providing information to the user on how to correct the error
(maybe the error is due to bad data that the user can correct, such as an
invalid date) so that he/she can simply continue (or try again), why always
show the error, especially since you're logging it? The error message is not
likely going to mean anything to the user unless you provide explanatory
information on what the user needs to do to correct it (again, referring to
bad data). That means special error handling code for specific errors. Let
me give you an example. Say the task is to import data from a file on a
floppy disk. The user forgets to insert a disk which is going to cause an
error (drive not ready). The logical thing to do is tell the user there's
no disk and have him/her try again (and provide an opportunity to cancel).
It's also possible the user inserts the wrong disk, for which you'd want to
show a different error message and give the user the opportunity to insert
the correct disk or cancel.

> bThereWasAnError = True
> GoTo Proc_Exit
>
> End Function

Never use GoTo in your error handler routine (really, never use GoTo at all
unless you ABSOLUTELY have no choice...and that's extremely rare). Use the
Resume keyword. For example:

Resume Proc_Exit

If you GoTo a line label within your error handler, VB's going to think that
you're still in your error handling routine. This could have negative
consequences, particularly since you're re-raising the error and I don't
believe ever cleanly exiting the procedure.

--
Mike
Microsoft MVP Visual Basic

Peter Plumber

2005-11-28, 3:55 am

Thanks a lot for the responses

Peter

Sponsored Links