Re: Error trapping code

Answers embedded.

--
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.

"Thelma Lubkin" <thelma@xxxxxxxxxxxxxxxxxx> wrote in message
news:dfb93r$v56$1@xxxxxxxxxx
> 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?

If you have added error handling to MySub, then when it calls a function
that generates an error, control is returned from the failed function to the
calling procedure's error handler.

The example above does not have error handling, so that won't happen until
you add the error handler to MySub.

> : 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?

Yes, that's what I do. The setup of the table is explained in the article:
http://allenbrowne.com/ser-23a.html

Some developers prefer to write the errors out to a text file, so that even
if the database corrupts you still have the log. IME, that's not a big
enough issue to be worth the effort. The bigger question is whether you use
a single network log for all workstations, or log separately on each
workstation. I prefer logging to a local workstation, because that still
works reliably even if the problems are caused by the network itself.

HTH


.

Relevant Pages

  • 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: Error trapping code
    ... : Sub MySub ... 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 ... 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)
Loading