Re: Re: DB Exceptions - Sample Code
| From: | Alan Knowles | Date: | Fri, 09 Jul 2004 16:48:38 +0000 |
| Subject: | Re: Re: DB Exceptions - Sample Code | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-31808@lists.php.net to get a copy of this message | ||
I did start sketching up when error codes might be usefull, taking the DB class as an example.
Assuming all exceptions where DB_Exception_* and extended a core DB_Exception (and may/maynot have some inheritance tree or something). It became clear pretty quickly that the codes where pretty pointless... - even justifying them as some kind of unique identifier for a specific version of the error didnt make much sense..
Speedwise, at present, I doubt there is any difference in preformance between defining a number of classes as opposed to the same number of defines. (it may be marginally slower if someone has fixed the define slowness). But Used well, it's probably going to be a huge improvement.
try {
$db->connect())
} catch (DB_Exception_PasswordInvalid $e) {
.. set up error.. - start the config program..
} catch (DB_Exception_DogAteConnection $e) {
.. email the Administrator, and Vet.....
}
Regards
Alan
Lukas Smith wrote:
Hans L wrote:-- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.comLukas Smith wrote:True interfaces could alleviate this limitation fairly well. But that would mean for every exceptions defined I would also have to define a corresponding interface. regards, LukasOnhe more point: inheritance in php means you can only derive from one parent. dunno if this is a serious limitation for categorization which should however be possible to overcome using error codes.If necessary, you could use interfaces to define the "categories" under which individual exceptions would fall. For example some of the DB_Exception examples clearly wouldn't be instantiated, anyway: interface DB_Exception_Constraint {} interface DB_Exception_Cannot {} class DB_Exception_Funky implements DB_Exception_Constraint, DB_Exception_Cannot { } This is a pretty rare case, but I can't think of a much more elegant way to solve this using an error code naming system.