Comments on: Exceptional PHP: Introduction to Exceptions

By: Jory Geerts

Jory Geerts — Tue, 10 Nov 2009 18:54:25 +0000

Brandon, I don’t really think its “much better to define a TwitterException and define the various types as codes”. If I recall correctly, you had some wrapping code around the cURL library, to abstract away from it and make things a bit more re-usable. (I might be wrong, obviously – can’t be bothered to go dig around and find that article.)
If you are then throwing TwitterExceptions in the cURL wrapper, the whole louse coupling idea kinda fails, doesn’t it?

But, nice article. Exceptions are a great way to make your programs more understandable and manageable. (And the rule of thumb you mention is dead-on.)

By: Hans

Hans — Tue, 10 Nov 2009 13:24:16 +0000

Yes thank you. Makes sense to put the result set validation in the application logic (at least in my case).

Thank you.

By: Brandon Savage

Brandon Savage — Tue, 10 Nov 2009 12:54:57 +0000

An empty results set is a perfectly valid results set. I would probably allow for an empty results set to be returned, rather than triggering an exception.

You might consider triggering an exception later on in the event that an empty results set should have been impossible. For example:

if(!$id) {
$user = new User();
} else {
$user = UserPeer::retrieveByPK($id);
}

if(!$user)
{
throw new ActionException(‘User object not loaded’);
}

Hope that helps!

By: Hans

Hans — Tue, 10 Nov 2009 12:38:13 +0000

Hi! Interesting post, would really like to learn more on the subject.

Is it bad coding practise to try and collect non-existant data from the database? Was contemplating the removal of a dbException which is thrown at the return of empty result sets. If yes – why?

By: Andy Thompson

Andy Thompson — Tue, 10 Nov 2009 07:45:46 +0000

Yes, sorry that’s what I meant by being feasible, I just thought from your examples that you were suggesting using the base Exception class and error codes.

By: Matt McKeon

Matt McKeon — Tue, 10 Nov 2009 04:20:45 +0000

I agree with Andy, extending the base Exception class seems more intuitive and strait forward then adding an error code. Isn’t that some of what Exceptions try and replace, ambiguous error codes?

I somewhat agree with you Brandon, in your example there are to many exceptions defined. But you don’t really need them all anyway.
Some of those can be lumped under something like NetworkException, ApiException, etc; I’d think most of them would be handled similarly anyway. So why burden yourself with extra Exception classes *or* confusing error codes.

By: Brandon Savage

Brandon Savage — Tue, 10 Nov 2009 00:55:37 +0000

I think it would be really rather silly to have an exception for each and every file in a library or action. For example, under your model, for a Twitter library we’d have:

* CurlException
* BadRequestException
* MessagePostFailedException
* ReadStreamFailedException
* and so on…

It’d be much better to define a TwitterException and define the various types as codes.

By: Andy Thompson

Andy Thompson — Mon, 09 Nov 2009 21:52:45 +0000

I’d disagree on the use of the error code to differentiate between exceptions. It would be better to define clear subclassing of Exception as much as is feasible before involving error codes.

Also, following that, throwing/catching the base Exception should probably be avoided, as all exceptions are based on it, so making it hard to differentiate between them.

By: David Coallier

David Coallier — Mon, 09 Nov 2009 14:38:19 +0000

Good article, however I think you should dive into the spl exceptions in order to get people interested in various types of exceptions (Exceptions we are encouraging in the upcoming PHP Recommended Standards for framework (or whichever the form that it’s being given))

http://php.net/manual/en/spl.exceptions.php