[AccessD] Tracing program flow

You can log the errors to a text file, John.  We do that in some of our
apps that involve an automatic restart.  One app shells out to open the
other.  Then they communicate through setting registry keys, although an
xml file would work as well.  Each app create a log file of each step in
the restart process from the perspective of that application.  If
everything succeeds as expected, the files are zapped.  Otherwise, they
remain to tell the programmers what went wrong and where.

Another way to handle it is by pushing and popping a stack detailing
each procedure and writing it out to a text file.  If the stack is empty
(everything succeeded), the file is discarded.

Charlotte Foust


-----Original Message-----
From: John W. Colby [mailto:jwcolby at colbyconsulting.com] 
Sent: Friday, May 06, 2005 3:08 PM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Tracing program flow


>you just have to be prepared that what can fail sooner or later will 
>fail.

Exactly.  The last system has been in place for a couple of years and
all kinds of weird errors have popped up.  In that case a message box
opened, halting the program flow.  The reports would not go out and I
could remote in to see the errors.  I want the process to continue so
that if a specific report failed for whatever reason, the next one would
go out (assuming no errors there), which means silent logging,
notification of the errors, and sufficient information to trouble shoot
the issue since I no longer have the program halted at the scene of the
crime so to speak.

John W. Colby
www.ColbyConsulting.com 

Contribute your unused CPU cycles to a good cause:
http://folding.stanford.edu/

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock
Sent: Friday, May 06, 2005 3:13 PM
To: accessd at databaseadvisors.com
Subject: Re: [AccessD] Tracing program flow


Hi John

Not to shortcut your clever thoughts and comments here, but it sounds
like you may expect a flood of errors. As you are capable of writing
robust code popping no messageboxes, my guess is that the only errors
you'll ever meet will be at the transmitting (mail, fax, ftp) process
where - on the other hand - all sorts of errors can arise and - worse
yet - you can't even set up a test scenario that simulates all these
errors; you just have to be prepared that what can fail sooner or later
will fail.

/gustav

>>> jwcolby at colbyconsulting.com 05/06 8:39 pm >>>
I am designing a system to create reports to be sent to a client
automatically every evening.  I did this before and had consistent
issues with error handling, msgboxes in error handlers popping up and
stopping the process etc.  This time there will be no msgboxes, but
errors must be reported thus I am trying to build a system that can be
called from the error handler or where a message box would pop up.  The
system will log all such messages.  Some thoughts in no particular
order.

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com