Re: Re: DB Exceptions - Sample Code
| From: | Sergio Carvalho | Date: | Fri, 09 Jul 2004 08:48:44 +0000 |
| Subject: | Re: Re: DB Exceptions - Sample Code | ||
| References: | 1 2 3 4 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-31777@lists.php.net to get a copy of this message | ||
Hans Lellelid wrote:
Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc
On the other hand, if all those empty classes were defined in one file, it probably wouldn't be significantly more overhead than having the define() statements. (I'd be curious to know.) & in the rare cases where that knowledge is required it certainly is elegant. Hmmm ... I suppose this belongs in the Exception RFC. (Sergio?) Exceptions do support codes, so I don't think we should erradicate them ... Perhaps this should just be up to the package.I see your point. I personally prefer to have different exception classes for all situations where the error types are defined at design time. I do understand, however, how people may want to avoid large inheritance trees, where the only gain introduced by the inheritance is classification of exceptions. Error codes are one type of classification. It's the simplest kind of classification: one axis, integer values. Inheritance trees are a more powerful type of error classification. There are concepts you can represent in an inheritance tree that are difficult or impossible with error codes. In our example, you could make DB_Exception_AlreadyExists a son of DB_Exception_ConstraintViolation, where constraint violation exceptions probably have the same kind of treatment. Moreover, the catch mechanism is designed to take advantage of exception hierarchy to select which exceptions to handle. Dropping the hierarchy in favour of error codes means code like the one Arthur used: catch the exception, and then extract the error code to see if you really wish to handle it; rethrow if you don't. Large trees of empty classes have two possible objections. One is the large conceptual tree, that may add to the complexity of the app. The other is the fact that PHP is in the field of interpreted languages, and suffers a penalty for defining each class, or including each file. Does anyone have numbers on the price PHP5 pays for these operations? If it is high, I'm in favour of the RFC including a provision for the usage of error codes when the exception tree is very linear. Otherwise, we should discuss it a bit more. Cheers, Sérgio Carvalho
Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc