I’ve been studying the use of exceptions in various php projects (such as Doctrine and Zend Framework). Exceptions seem to be thrown when unordinary input/state occurs. A perfect example is Doctrine throwing an exception when you try to use a invalid query string.
I think the creators of the doctrine api understood that first, you can’t query data by using an invalid DQL statement, and a developer should immediately be warned that an error has occurred, rather then letting execution continue with the possibility of an error code going un-checked. I also bet that this simplifies reading the code. I can’t think of a situation where you would want to use an invalid DQL statement, except unit testing. Since this is true, it’s better to avoid plaguing a bunch of code with null/error checks and use exceptions.
I’ve read in books that exceptions shouldn’t be thrown when validating dating user input. I’ve seen examples where of where the guideline is broken. One example is the Zend framework. If supplying an invalid controller or action name, an exception is thrown. Unlike doctrine, the user has more direct control over this sort of input. I know you can configure an error controller and set up a 404 message or what have you, but I’m curious why they have used an exception in this scenario? I guess you can argue the Zend Framework does not know how to continue processing the request.
One last example Is I wrote a function to return some html based on a given resource type. This resource type is hard-coded and sent when a user interacts with a web site (such as clicking a button to display the form to input data). I don’t expect users to be mucking around with the request type. Under normal operating conditions, the resource type should be valid. To clean up some logic, I was going to throw an exception if a particular form wasn’t found. This is mainly to find the correct form associated with a resource type so proper validation can occur. Does this sound like a valid use case for an exception? Right now it’s pretty trivial, but I do plan to implement a restful consumer and re-using a function to map resources to their validation services would be very useful. I can then catch the exception and based on the consumer, return an error message suitable for the request type…
3
Exceptions should be thrown in exceptional cases, such as a circumstance where the expected file doesn’t exist, or when network is down, or when it takes more than a minute to open the connection to the database.
Wrong user input is not an exceptional case. It may not even be an error. For example, entering “twenty six” in Your age field is not an error from users’ point of view, but still most applications wouldn’t be able to handle this input as valid.
Instead of throwing an exception, the app should validate the input and, if it really can’t be parsed, return either the HTML response indicating what is expected as input, or, in a context of AJAX, a JSON with the details about the invalid input.
This is the theory.
In practice, frameworks such as Zend Framework or ASP.NET MVC recur to exceptions, because there is no elegant way for them to handle invalid input. They are frameworks, not apps. This means that at some point, they should/can/might pass the info such as “Hey, I can’t parse the Age field as a number!” to the application. The least ugly way to do it seems to use exceptions.
1
One should return error indications for things an immediate caller is prepared to handle, and exceptions for things an immediate caller is not prepared to handle. If conditions may arise while performing an action that some immediate callers will be prepared to handle but other immediate callers will not, it may be helpful to have a method which will return an error indication in such cases (for use by callers that are expecting the condition) and another method which will throw an exception (for callers which would be unable to do anything in the error case except throw an exception themselves).