Re: Re: DB Exceptions - Sample Code
| From: | Lukas Smith | Date: | Fri, 09 Jul 2004 12:10:20 +0000 |
| Subject: | Re: Re: DB Exceptions - Sample Code | ||
| References: | 1 2 3 4 5 6 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-31785@lists.php.net to get a copy of this message | ||
Hans Lellelid wrote:
Hi Sergio, Sergio Carvalho wrote:Well lets say you can define them in a more straightforward way. You can define a system of how error codes are to be named that enables classification in much the same way. Defining these rules is quite a task however. The advantage is that once you have it, those people who now this ruleset can quickly get alot of information by just looking at the error code itself, whereas its alot more difficult to remember full inheritance trees if you use them for classification. I dont have experience defining anything like that, so I will refrain from giving an example for now. However the SQL standard for example defines such an error code classification IIRC. regards, LukasError 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.It's a good point that inheritance trees are a more powerful type of classifiction. You can represent generalities & relationships in a way that isn't possible with the codes. And certainly these subclasses can store specific information, which makes the argument re: empty subclasses go away.