>I code defensively and rely on good architecture and testing to facilitate the creation of robust solutions - however, I cannot guarantee that I will catch 100% of the possible errors. Hence the need for ON ERROR and TRY ... CATCH. When the Open Dialog appears I am no longer in control, to think anything else is a case of being 'economical with the truth'.

I never get "Open Dialogs" ...

My idea of coding defensively is to open EVERY table (required by a given "process" in a "session" object), and acquire all necessary table / record locks explicitly at the START of every "task / process / transaction" to insure that process has the highest probability of running to completion; virtually all "file" type problems are caught at this point and can be handled via an error routine. And no keeping the User "in suspense".

Running a process and opening files, "as we go along", is a little too risky for me and means I have to spend a lot more time thinking about back-out / recovery procedures.

All "process tables" are subsequently flushed and closed at the end of a process.