I Agree with Carl
All erroes whould be trapped even if its just to provide a more polite
message to the user that something has gone wrong tather that having the
weird message "Object x does not support method Y" etc.
It also allows you to gracefully exit the application by properly closing
resources in use such as open files or ado tables,
network connections, references to objects etc. etc. etc.
> > I prefer to enable error trapping *only* when I suspect an error is
> > possible. If the error occurs, handle it, clear the error and disable
> > error trapping. If an error occurs somewhere that I didn't anticipate,
> > the user will get a run time error message. I'll hear about it and
> > have to fix it.
> Hmmm... Rather than having the application crash in front of a user
because
> there was no error handler, I prefer to trap all errors and log them if
> nessessary, then show a "friendly" critical error message to the user.
This
> means that all top-level procedures have Event Handlers.
> --
> Thanks,
> Carl Prothman
> Microsoft Visual Basic MVP
> http://www.able-consulting.com
> Please reply in the newsgroup. I am unable to respond to requests for
> assistance via private e-mail.