Re: Re: DB Exceptions - Sample Code

Hi Sergio, Sergio Carvalho wrote:

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.

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.

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.

Yeah, I don't think we should drop the hierarchy by any means. I'm just not sure that we should replace codes with hierarchy in every case. I'm not sure the exception RFC should suggest a *requirement* in this regard, but I definitely think that your arguments should be in there. I can imagine packages on both sides of the spectrum.

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.

Yeah, that's a good point: if the exception tree is flat / linear and the specific "reasons" are deemed inconsequential by the package writer then codes is probably a better way to go. Of course, inconsequential to one package is critical to another, but at some level packages do have to make decisions about what matters. Hans