Re: parse errors when testing for undefined exceptions

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