Errors welcome 3

[Olaf Doschke]

...and yes, Mike, if I wanted to make sure the error is not something different, I should check if the error is really 'File does not exist'. But it would be rather weird if something else would be wrong.

If you take it serious you never should catch an error with a simple Catch block, as all kind of errors could happen. But then you're back to using a global error handler very soon, or you'd shut down your app on every error just to make sure it's not causing trouble.

Bye, Olaf.

 

[calloatti]

@Mike:

There is no typo, maybe my explanation was a bit lacking:

The whole idea is to have a VFP function and a DLL declare using exactly the same name.

When you make a call to the VFP function/DLL declare for the first time, the VFP function is called.

The VFP function declares the DLL function using exactly the same name, and then "calls itself", BUT, since DLL declares take precedence over VFP functions, the DLL function is called this second time, and NOT the VFP function with the same name.

Then, every other call to the function just calls the DLL function, not the VFP function.

If CLEAR DLLS happens to be used in the code, then the VFP function will be called the next time you use the function, which will declare the DLL function...

To use this method, you just need a prg with all the functions, and do a set procedure to...

Carlos Alloatti

 

[Olaf Doschke]

Thanks Mike, for checking this out. I would have thought so, as you're not only dealing with a try block overhead, but a function call. So were you can use the precedence it's even better. You can for example also override vfp functions, eg I think a procedure within the main prg has precedence over a stored proc and there are several more precedence rules of that kind.

But I also think about simpler cases as type errors you could trap and handle in a catch block rather than with more expensive prechecks. Especially if you expect the error case to be the more seldom one.

Bye, Olaf.