> With VFP's Error method it's perfectly possible (though impractical) for > every object to have it's own error handler, and not deal with a general > error handling routine at all. From a theorhetical view, providing such > would assure encapsulation. Practically, however, having an error handler > that could handle every error with every object would unnecessarily drain > system resources, since each instance of an object would bring an > additional copy of the routine into memory. I'd suggest a balanced appproach: object/class error trapper should trap the object specific errors, and pass the rest to the general routine, p.e. in a combo's trapper it could trap for zero-length source array, empty source table and other specifics, and pass "record is out of range" and such things to the general error handler. I've also written one routine of a kind, though it cumulated its notifications into a (classical) error.log; each user had one, and I had another maintenance routine to gather them all into a master log. It didn't pretend to be much inteligent - it closed files, flushed buffers and wrote everything down, notified the user (with a sufficiently long text, which they could print out) and then simply quit. The bad side was that it ocasionally wrote records which were already written, so it created doubles sometimes. The log contained full call stack, offending program line, mess() mess(1), currently selected alias and any debugger... well, I've planted a debug_msg variable into various critical places of the app, so if it existed at the moment error handler was called, it was logged too. It was quite useful to have it defined before calling a general purpose routine, so it could mark the exact point where the routine was called from and for what reasons. Worked real fine.