Re: Re: DB Exceptions - Sample Code
| From: | Justin Patrin | 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--