Should the PHP community start using more descriptive Exceptions?

Question

I work with Zend Framework a lot and I just took a peek at Kohana, and it strikes me as odd that this is a typical scenario in these frameworks:

throw Some_Components_Exception( 'invalid argument' );

Where I believe this wouldn't be much more useful:

throw Some_Components_InvalidArgumentException( 'whatever discription' );

Because it is easier to catch.

I suspect, but immediately admit it's prejudiced, that the former practice is common in the PHP community. Should we, the PHP community, start using these descriptive types of expections more?

Answer 1

Yes, I would recommend using the Exception subtypes provided by SPL. It allows calling code (either in a framework or in your app) to handle different types of exceptions differently.

A DomainException might indicate invalid user input, which you should report to the user and give them a chance to re-enter data. A BadMethodCallException may indicate a flaw in your code, and you should log it and handle it a different way.

But these different exception scenarios have nothing to do with the class or component that threw the exception. A BadMethodCallException should probably be handled similarly whether it happens in an MVC component or a DB access layer.

I was the project lead on the Zend Framework through its 1.0 release. I wanted to reorganize the exception hierarchy, and I thought it was an arbitrary decision (prior to my joining the project) to use a single exception for every component. It didn't make sense.

Unfortunately, rearchitecting the exceptions wasn't as important as getting the product to its 1.0 release milestone. I had to follow the priority on schedule that Zend set for the project, and to do that, practically everything that wasn't strictly necessary to get to the feature-complete release had to be deferred.