parse errors when testing for undefined exceptions

aghh.. - another crap example:

The priciple it was try to make was that

....
require_once 'MyException.php'
throw MyException(....);
....

then trying to catch MyException leads to a parse error when it's
try()'d and not loaded.

Regards
Alan

Alan Knowles 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

aghh.. - the previous example was crap

The priciple it was try to make was that

....
require_once 'MyException.php'
throw MyException(....);
....

then trying to catch MyException leads to a parse error when it's
try()'d and not loaded. means we cant lazy load any Exceptions, and save
file io/memory etc.

Regards
Alan

Alan Knowles 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

in your function, you should assume sqlite is present.
before calling any functions, have one of the first actions in your script
(preferably in some file you include always anyway) be a check on the
existance of sqlite.

problem solved?

"Alan Knowles" alan@akbkhome.com schreef in bericht
news:4135C8C3.5000705@akbkhome.com...

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

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) {};'

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...

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

--
Best regards,
Marcus mailto:helly@php.net