Ken,

I should have added (and see now that Christof L. has also suggested) that an update of the documentation would be in order.

In addition, somewhere in the Programmer's Guide (online) I came across a bit of code using VARTYPE to check if an object exists as an object. Needless to say, that (now) looks like a bad idea.

Cheers,

Jim N

>Thank you, Ken.
>
>Yes, it is now perfectly clear, and I accept without qualification that it is 'properly' designed.
>
>Cheers,
>
>Jim N
>
>>>> >You speak very authoritatively. Can I assume that you are a member of the VFP Design or Management team? <<
>>
>>Yes, I created and wrote the specifications for VARTYPE().
>>
>>>> I must also say that this is, to say the least, an unusual situation for any computer 'language' that I have come across - that, BY DESIGN, a command may cause an Exception. <<
>>
>>There is no exception occuring with VARTYPE(). The exception is occuring in your evaluation of some expression before VARTYPE() is called, which is why this behavior is by design.
>>
>>>> I hope that the powers that be reconsider this stand. <<
>>
>>This is unlikey, since it currently behaves as intended.
>>
>>Let me explain the design to clarify the misunderstandings. VARTYPE() is a function that receives value, just like TRANSFORM() or whatever. If you say TRANSFORM(1+2), it returns "3", and 1+2 is evaluated before TRANSFORM() is actually called. If you say VARTYPE(foo), the value of foo is passed to VARTYPE() after it is evaluted.
>>
>>Now, here is the confusion. In order to increase the value (common usage) of VARTYPE() vs. TYPE() since VARTYPE() is much faster and returns "X" for NULL values, VARTYPE() has a "special" ability unlike other VFP functions and that is if a variable (not an expression or object.propery) is passed to it that doesn't exist, it would return "U" instead of causing a runtime error. This is considered a feature, and I'm certain that most developers like this enhancement to VARTYPE(). I think the confusion here is that this special behavior is misleading developers into thinking it can return "U" for any invalid expression, but that's not the design. You need to use TYPE() for expressions that may cause a runtime error. Hope this helps clarify this issue.