>>If CREATEOBJECT() fails for any reason other than the Init returning false, I would certainly expect an error message. Something like "Insufficient Memory" - something related to the reason that it failed. To suggest otherwise implies that VFP shouldn't really report any errors at all.
>
>Agree. Do you have an error handler active that might have caught the error?

Yes. That error handler is properly catching and logging the "LOPRINTGEN is not an object" error. My first reaction to this was to check if it was possible for the class Init method to return false. The method is very short, and doesn't have any explicit returns at all, which implies that true is always returned. Although just typing that last sentence made me wonder if it's possible for VFP to return false in some strange cases if there is no explicit RETURN command.

>
>>I agree that if the Init returns false, then it's up to the programmer to handle that. But if CREATEOBJECT() simply doesn't create the object, how am I to determine why? And why should I have to test the variable after every single CREATEOBJECT() statement? I don't think that's a viable solution at all.
>
>It's called defensive programming.

I agree with you that defensive programming is needed in many cases. I don't think this is one. If I put defensive code in for this, I'd be treating the symptoms, not the cause. Other situations where you have to put in defensive code are different, as in dealing with all of the things that a user might do. Or when dealing with functions that don't trigger the normal error handler, like the low-level file functions (FOPEN(), FREAD(), etc.).