Re: Error trapping code

Allen Browne <AllenBrowne@xxxxxxxxxxxxxx> wrote:
: Thelma, an example might help to explain rkc's suggestion.

: Say you have a procedure that calls another proc like this:
: Sub MySub
: Debug.Print MyFunction()
: End Sub
: Function MyFunction()
: MyFunction = 6
: End Function

: Now if you add error handling to just MySub, and an error occurs when it
: calls MyFunction, the error handler in MySub will catch the problem when it
: calls MyFunction and the problem occurs.

Actually, I don't really understand that. Suppose I have

Sub MySub
Debug.Print MyFunction(0)
End Sub
Function MyFunction(denom as Integer)
MyFunction = 6/denom
End Function

Why does execution return to MySub so that the error can be trapped
instead of simply dying in MyFunction?

: While that's true, I prefer to add error handling to MyFunction anyway. The
: main reason is that I find it much easier to track down an error if I know
: what procedure caused it. Particularly when you get one proc that calls
: another that calls another ..., I'm too lazy to try to track down which one
: actually caused the error, when I can get Access to gell me just by using
: error handling in each one. The other reason is that later on I may need to
: call MyFunction() from somewhere else, so I really prefer just to have the
: error handlers in place anyway.

I intend to write a single function that gets offending
sub/function name, etc, as parameters, to report error messages
to the end-user, and after reading your earlier post, I think
that I'll use it to save those messages for the
developer/maintainer as well. Do you just add a table to the
database for these?

Thank you for the help. --thelma

: --
: Allen Browne - Microsoft MVP. Perth, Western Australia.
: Tips for Access users - http://allenbrowne.com/tips.html
: Reply to group, rather than allenbrowne at mvps dot org.

: "rkc" <rkc@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
: news:N_2Se.49754$EX.9464@xxxxxxxxxxxxxxxxxxxxxxx
:> Thelma Lubkin wrote:
:>
:>> My question is, therefore, should error-trapping code bookend every sub
:>> and function? If not, what criteria do I use to decide whether to add
:>> it or not?
:>
:> Functions, methods that return a value to a calling procedure, don't
:> necessarily need error handling, but the calling code certainly should
:> have it. Objects(class modules) should trap an error and pass it on to the
:> client code.


.

Relevant Pages

  • Re: Error trapping code
    ... >: Function MyFunction() ... Now if you add error handling to just MySub, and an error occurs when it ... If you have added error handling to MySub, then when it calls a function ... calling procedure's error handler. ...
    (comp.databases.ms-access)
  • Re: Error trapping code
    ... Sub MySub ... Function MyFunction() ... Now if you add error handling to just MySub, and an error occurs when it ... I prefer to add error handling to MyFunction anyway. ...
    (comp.databases.ms-access)
  • Re: Finetuning: Remote Shutdown with WMI, some errors occur.
    ... These errors are indicative of network problems or timeouts or something ... ping and then goes down. ... Function myFunction() ... 'Put other error handling here ...
    (microsoft.public.windows.server.scripting)
  • Re: 1004 "Application-defined or object-defined error"
    ... If you're calling =myFunctionfrom a worksheet cell, ... > Function myFunction() As Integer ... > But the same code works inside a sub: ... > Sub mySub() ...
    (microsoft.public.excel.programming)
  • 1004 "Application-defined or object-defined error"
    ... Function myFunction() As Integer ... On Error GoTo Error ... But the same code works inside a sub: ... Sub mySub() ...
    (microsoft.public.excel.programming)
Loading