GB>>3. If a library has an obscure bug in __autoload, the only error message GB>>the user will see is:
GB>>
GB>>"undefined class XXXX"
GB>>
GB>>If __autoload() is going to gain the ability to be defined for a GB>>library, then the error messages must be enhanced as well.
Shouldn't that bug result in some error message by itself? If it doesn't, there's probably nothing to add to "undefined class" anyway.
I meant a logic error - as in the user forgot to use a DIRECTORY_SEPARATOR and so can't find any of the classes, not an obvious PHP error.
GB>>1) document that coders of __autoload() should throw an GB>>autoload_exception if a class is not found
Why just not return false or something? Exception is supposed to be used when things are so bad you just can not continue. But I don't think class not being found is such situation for autoload.
On the other hand, I think that multiple autoload functions should be evaluated in isoplated way - so that exception, etc. in one of them would terminate it, but not the whole autoload process (i.e., next one would be run).
Perhaps a better solution is to simply augment the "undefined class XXX" method with a brief listing of all the defined __autoload() functions, so the user knows where to look for magic bugs.
Greg
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
