Marcus Boerger wrote:
Hello Alan,
juts for the record, you can even __autoload the missing exception class:
php -n -r 'function __autoload($n) { var_dump($n); eval("class $n extends Exception {}"); } try { } catch(ExcetpionXYZ $e) {};'
dont you think this is a really horrible kludge?
and besides what should the compiler do? Guess what that exception you specified
might be? That's like expecting functions were present of the not loaded
extension...
if (!function_exists("hello_world")) {
....
}While I can understand there is some language design desire to verify that a class exists so that you have not done a typo, It goes against the grain of a runtime language that loads only the components (eg. classes/extensions) as it needs them.
How about:
try { } catch ("ClassName" $e) { ..... }
if ($e instanceof "ClassName") {.....}This would allow you to do only explicit classname testing rather than class exists and type testing
Regards Alan
regrads marcus
Wednesday, September 1, 2004, 3:04:03 PM, you wrote:
This is a simple example of why making a parse error out of undefined Exception types is going to be very problematic.
function test($a) {
if (!extension_exists('sqlite')) {
return;
}
try {
SQLite::query($a);
// parse error!!! - if we dont have sqlite, we dont have SQLite exception!
} catch(SQLite_Exception $e) {
echo "problem with query";
return;
}
}
This has a big knock on effect that we can not lazy load Exception definitions, even if they are only used in Exceptional situations. (its pretty much the same issue as instanceof - forcing the loading of code, that may never be used, except to test it's non-existance.)
Regards
Alan
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
