Re: Re: DB Exceptions - Sample Code

Alan Knowles wrote:

This does raise an interesting question about how instantate it in code: ... oops something gone wrong.. require_once 'DB/Exception.php'; throw new DB_Exception_AlreadyExists('some message'); or this could be wrapped locally: $this->throwException('AlreadyExists', 'some message'); (assuming all DB_Exception_* are in DB/Exception.php) The inheritance tree would look like this? DB_Exception extends PEAR_Exception {} DB_Exception_AlreadyExists extends DB_Exception {} .... While I dont really like having lots of empty classes, it looks like the lesser of all evils :)

I'm surprised to find myself leaning toward practicality and away from academic design (Alan, I'm surprised you liked that idea!). I would say that while using exception classes instead of error codes is perhaps ideal, I don't see it being all that practical in PHP. In my experience a db error is generally a db error and having exception-type knowledge about what specific type of error was thrown is not important 99% of the time. For the rare cases, a return code could be checked. Noteably, even Java, which usually errs in the opposite direction, doesn't differentiate between the types (i.e. reasons) of SQLExceptions in JDBC. Perhaps it's useful to distinguish between a "type" of exception (e.g. SQLException, IOException, PEAR_DB_DataObect_Exception) and the *reason* for an exception (NO_DATABASE, DATABASE_EATEN_BY_RATS, etc.). The latter being represented by error codes (and the text messages themselves, of course). I can see that line between type and reason being dotted and shifting, though. I.e. sometimes the reason is important enough to warrant a different type. 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. Cheers, Hans