Re: Re: DB Exceptions - Sample Code

Arthur Hundiak wrote:

I do think the specific exceptions should be setting their own DB_ERROR code instead of it being passed. But I have not looked at the best way to do this yet. PEAR_Exception plays some games with the code and I don't want to have to duplicate it.

Right, PEAR_Exception does some magic to support several signatures. Of course, if the subclasses are specifying their error codes then they'd need to override constructor afterall. :) I'm not sure if you need codes, if you are using subclasses, though. Having both seems overkill. I see what you're saying, though, about the magic in PEAR_Exception. It's a bit of a limitation right now, actually. I'll fix it. If you wanted to add codes, you'd want to do: class DB_Exception_ConstraintNotNull extends DB_Exception_Constraint{ public function __construct($msg, $cause = null) {

    parent::__construct($msg, $cause, DB_ERORR_CONTRAINT_NOT_NULL);

} } The current design of PEAR_Exception will need to change a little bit to accommodate this. Specifically, in the constructor: if (is_int($p3) && $p2 instanceof Exception) { should be: if ($p3 !== null) { So that it supports a signature like throw new PEAR_Exception($msg, null, $code); I'll fix that in PEAR_Exception, as it's a good idea anyway. (Tomas, any objections?) I'm still not sure I see a need for codes and class types, though, since the information is redundant. Hans