Re: Re: DB Exceptions - Sample Code

From: Date: Fri, 09 Jul 2004 17:03:07 +0000
Subject: Re: Re: DB Exceptions - Sample Code
References: 1 2 3 4 5 6 7 8 9 10 11 12  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-31810@lists.php.net to get a copy of this message
I'm +1 on the inheritance trees for Exceptions. It would make catching certain classes of errors (as well specific ones) much easier and more straightforward. I'm +1 on requiring classes instead of error codes as it would unify the way that you deal with specific errors. Catching, then checking a code and re-throwing is a very bad way to do things. On Sat, 10 Jul 2004 00:48:38 +0800, Alan Knowles <alan@akbkhome.com> wrote: > 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: > > > >> Lukas Smith wrote: > >> > >>> Onhe 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. > > > > > > 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, > > Lukas > > > > -- > Can you help out? > Need Consulting Services or Know of a Job? > http://www.akbkhome.com > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > > !DSPAM:40eec8ce318901521720645! > > -- DB_DataObject_FormBuilder - The database at your fingertips http://pear.php.net/package/DB_DataObject_FormBuilder paperCrane --Justin Patrin--

« previous php.pear.dev (#31810) next »