Re: Re: DB Exceptions - Sample Code

Lukas Smith wrote:

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.

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.

You can certainly categorize / classify error codes in some sort of hierarchy system, but the point of using the class hierarchies is not for readability (we have messages for that) but so that you can selectively catch() these errors in your scripts, or catch() groups of errors, etc. I can't think of a more natural way of representing hierarchy in OO languages. So, if hierarchy is important to error codes, exception subclasses seem the way to go. If the error codes are flat then I'd probably use error codes -- if anything. Depends on the package, I feel. Hans