7

I am working on a PHP framework and am currently designing error handling. Based on what I have read on SO, I should only use exceptions for, well, exceptional situations. Therefore throwing an exception when an incorrect password is entered is wrong.

Should I avoid using exceptions when I want to return a server error code to the user (eg. 404 Page Not Found)? If so, should I write my own error handling class?

Peter Horne
  • 6,472
  • 7
  • 39
  • 50
  • I have a followup question for anybody answering this one -- Suppose a user visits a page with 3 records on it. They click on a link to edit a particular record but between the time the list page was rendered and the time they click the record, that particular record was deleted from the database. Should the edit page throw an exception when the database retrieval function returns NULL? Obviously the code rendering the view would handle such exceptions and display an appropriate error message, but I'm curious about how such a situation would be handled internally. – aw crud May 07 '10 at 18:58
  • @RenderIn If the controller/view could set the response to 404, and display an appropriate "that's missing" page - I'd say that's the best place to handle it (see my answer). That said, when you're prototyping something, it's alot easier to just throw the exception knowing the error controller will at least alert the user that the request wasn't successful. – Tim Lytle May 07 '10 at 19:37

4 Answers4

8

Your code shouldn't throw an exception to interact with the user, it should throw the exception to notify a higher level of code that something unrecoverable happened.

Now, depending on what happened, you may want to respond with a certain HTTP status code. But at that point you're not throwing exceptions to trigger a server error, you're catching exceptions and giving the user an appropriate response.

If the questions is what should happen when an article/blog/item/etc is requested that doesn't exist -- well, if it's possible for the code responsible for displaying the information to just set the response code, then by all means, don't use exceptions.

If you're using a MVC framework, and your individual controllers can set the response code, then let them.

And if the topmost exception handler can use a http response code to better present the error message to the user, then let it.

Tim Lytle
  • 17,549
  • 10
  • 60
  • 91
  • Added a bit of an example. I must say, right now I'm a having a hard time thinking of a situation where a response code would be helpful at the top tier exception handler of a MVC framework - assuming you can set the response code in the controllers. – Tim Lytle May 07 '10 at 19:07
2

Exceptions are not control flow mechanisms.

Adrian
  • 1,392
  • 9
  • 9
1

Exceptions should be limited to ONLY those times that the app truly can't handle the situation.

As you said, throwing an exception for an incorrect password is very wrong.

The only server error type situations I can come up with are if a required resource (like your sql server) wasn't available.

Beyond that, access denied, etc are all common occurrences that your application should have a normal way to handle.

NotMe
  • 87,343
  • 27
  • 171
  • 245
0

I think you are talking about two different things:

  1. Errors that occurs when something has gone wrong in the framework itself, or the framework is used in a way that it should not work.
  2. HTTP status codes (404 Page Not Found mentioned in the topic is status code).

In the first situations throwing exception is the right way to do, if you want to solve the problem by using object orientated approach. HTTP status codes are part of the HTTP protocol and your framework should not handle them in any way.

pkainulainen
  • 1,458
  • 1
  • 19
  • 51
  • OOP has nothing at all to do with throwing exceptions (Framework or not). The only thing that matters is whether it is a situation that can be dealt with or not. If the situation is so grave that the application must basically throw up, then yes a nice exception with details about the problem is good. However, if it is something that you can work around either by telling the user they can't do that, asking for more information, or by taking a different path with the command, then don't use an exception as the problem is quite unexceptional. – NotMe May 07 '10 at 18:16
  • "HTTP status codes are part of the HTTP protocol and your framework should not handle them in any way." There are a number of situations where I would like to return a 404 if there is no information contained in my models, surely the only way to do this is to trigger a 404 error in my code? – Peter Horne May 07 '10 at 18:32
  • Just out of curiosity, how many languages not using OOP do really support throwing exceptions? I have been used to see that return codes are used instead of throwing exceptions. So, because of this I have thought that programming languages following some other paradigm than OOP do not support them. Perhaps I am wrong then. – pkainulainen May 07 '10 at 18:33
  • "There are a number of situations where I would like to return a 404 if there is no information contained in my models, surely the only way to do this is to trigger a 404 error in my code?" Yes. That is true. In that case you should really throw an exception and set the HTTP status code to 404 when you catch the thrown exception. – pkainulainen May 07 '10 at 18:35
  • 1
    Oh, and not concerning the usage of exceptions (Yes, I know this a blog post using Java as an example, but it really explains the idea of using exception): http://wolfie.github.com/2010/03/14/exceptional-heresy.html – pkainulainen May 07 '10 at 18:42