>>Now the question may exist what about the error, should it occur.
>
>A while ago I wrote OO wrappers for Data, and the method for OpenTable (=Use) was longer than I thought it would be. It went throught the whole exclusive, again, alias, workarea and all the other jazz. One of the things I thought about was the error thing (error 1, 1705, ect.) and I would decide it by a parameter to the method, and if that didn't exist, it would be the state of the lSuppressErrors property in the class.
>
>Most of it was handled in the Error() method of the class, so, would that be the correct way to handle it?

Hi Mike,

Probably in a similar fashion. Depending on the design, in some instances it's possible to recover from the error transparently and proceed. For example, if the index tag is not found, the index had been deleted, or something similar, if you had stored the tag names and expression in a table (or parsed the information from the DBC), you could re-build the index and proceed.

It's been my experience that presenting the user with an open file dialog in the instance of a file not being found, isn't a really good, workable solution. In most cases, if the file isn't there, it's either been moved, deleted or renamed, so the user is pretty helpless.

Largley, how the error is handled pretty much depends on how much time and thought you put into designing the handler. The more, the better. I would say that from a design standpoint, as I said before, neither the caller nor function itself should worry about these details, but only success or failure.