Re: __autoload & exceptions
| From: | Andi Gutmans | Date: | Sun, 12 Oct 2003 11:24:01 +0000 |
| Subject: | Re: __autoload & exceptions | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-4804@lists.php.net to get a copy of this message | ||
Dan,
__autoload() is the last chance to load a class which is needed before erroring out and terminating the script. By design, if you don't take advantage of this last chance the script will error out. Therefore, throwing an exception inside the __autoload() function should not be catchable by your script.
I hope that explains things.
Andi
At 01:34 AM 10/12/2003 -0400, Dan Cox wrote:
Marcus- Here are just some interesting observations with __autoload() and exceptions: Currently, an empty php file with just "throw new Exception();" will dump out an error like so: *Fatal error*: Uncaught exception 'exception' with message 'Unknown exception' in /server/http/sites/db.wep.net/htdocs/test.php:2 Stack trace: #0 {main} thrown in* /usr/local/apache/htdocs/test.php* on line *2 * OK, that's expected.. Now try something like this: function __autoload($x) { throw new Exception(); } $foo = new bar(); Will just give you: *Fatal error*: __autoload threw an exception in* /usr/local/apache/htdocs/test.php* on line *3* NOTE: The exception does not actually have to happen inside the __autoload function. It can occur in another function the autoloader calls with the same results. Obviously, exceptions *should* be caught and none of the above is valid code. I've seen a few bug reports other people filed in regards to exceptions that were answered with a similar argument like the one you stated.. sometimes exceptions are generated deep inside the engine where not much information is available. Taken at face value, that sounds perfectly reasonable; however another way of saying that would be "The handling of fatal, script ending, runtime exceptions will be mostly consistent, but sometimes may contain minimal or even useless information depending on where it occurred." :) This behaviour isn't a show stopper. It's just the inconsistency that bugs me. I'm left wondering what other ways the engine might handle my exceptions that I might not expect, like... try { function __autoload($x) { throw new Exception(); } $foo = new bar(); } catch (Exception $e) { print('caught exception'); } The exception will never be caught in this case (resulting in the same previous error). A PHP engine developer might look at that and say something like "oh, of course it doesn't. The engine removes the special __autoload function from the main try/catch block at compile time." Now try explaining why it would do this to your average PHP user. ;) Luckily, using a try/catch block *inside* the __autoload function works fine. Its just not at all able to pass the exception on up the chain. Meaning people need to keep in mind that any and all objects/methods/etc. which could throw exceptions that may have been called from inside their __autoload function will only get those exceptions passed as high as the autoloader for handling instead of their main code. If this is intended behaviour, then this is just a recommendation for a note in the future documentation of __autoload. Dan Cox Marcus Börger wrote:Hello Dan, Friday, October 10, 2003, 8:36:48 PM, you wrote:-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.phpOn a side note, when an exception is thrown from inside the __autoload() function, PHP only reports 'exception thrown in __autoload' and no other information about the exception. Is this a bug?I don't think so. The exception shows as much information as is available. Only sometimes the exception is generated deeply inside the engine where not many additional information can be accessed. And don't forget: Exceptions should be exceptions.I understand. For some reason, I just thought that self:: and parent:: were evaluated at runtime instead of compile time.Hope you get that straight now. parent & self must be considered beeing compiletime things.