[AccessD] No MsgBox allowed

I am doing a rewrite on an app that runs unattended and emails (or FTPs)
files out to a client.  This app absolutely must run, or at least if it
fails it has to NOT pop up a message box and halt the process.  The process
can send many different files, as well as importing data into the database.
I want the piece that fails to error. log the error, email a notification of
error, and exit so that the next process can attempt to run.  The next
process may well run just fine.

Many of you are familiar with my error handler insertion wizard that inserts
error handlers in any function, sub or property, and can do so for an entire
module.  I have used it forever and have in general been satisfied with it.
Until now.  It of course creates a default message box displaying a message
box for any unhandled errors.  Now I need all errors logged to disk, and the
error log mailed to a list of email addresses when errors are encountered.

Thinking about this immediately raises a slew of questions.  I use a
framework that sets up a host of functionality.  What happens when the
failure is so early in the process that it can't even do logging or send an
email?  How do I know how early that is?  My framework has to be rewritten
to log errors and email them as well (where possible), since obviously if my
framework errors we don't want that hanging the app.  OTOH, some errors can
be ignored, others should stop the app.  If I have classes in the framework
used by the app (and obviously I do) how do I get errors in the framework
code to log in the app error log?  IOW, the framework has a wrapper class to
copy files, create directories etc.  If that code fails, it can log an
error, but it will log to the framework log, not the app log.  

In a similar vein, does every function return an error code so that anything
that can go wrong is checked and logged?  If it returns an error code, what
if it needs to return a string, i.e. how do you return an error and a value
at the same time (I know, pass a parameter - that was just to highlight the
issue)?

My objective here is not to write a "can't possible crash" thing, but rather
to intelligently determine what can be logged and emailed and what is so
severe that.. well... it just pops up a message box and someone has to come
look for the problem.  Those kinds of things should rarely if EVER happen at
the application level though.  Just because a link for an excel file is bad
doesn't mean the next report process will fail, only that THIS report
process can't continue.

The program I am replacing had the old "pop up an error message" for
unhandled errors and it just seems that over time you continually run into
new things that couldn't be (or weren't) anticipated.  Every month at least
the files don't go because the program is sitting with a message box up.

Aside from the obvious "Access is not the optimum environment to write such
an app", has anyone done stuff like this (in Access) and do you have any
thoughts on the issues above or any others I haven't raised?  Thinking about
this concept gives a whole new appreciation for major apps such as Windows
and Access where they should always do something intelligent even in the
face of problems not even existing at the time the program was written.

Just a few things to get you thinking.

John W. Colby
The DIS Database Guy