Page 1 of 1

Exceptions as fatal http errors?

Posted: Sun Mar 04, 2007 6:30 pm
by Ambush Commander
I am currently using a function named display_error_and_quit() to fatally error out of applications, give an error message, and send the appropriate HTTP status code.

I just, however, remembered that I was programming PHP5, and we have these little thingies called exceptions.

Would it be appropriate to instead throw an "HttpException" (better name please?), which, when uncaught, displays the relevant error page through a global exception handler?

Posted: Sun Mar 04, 2007 6:46 pm
by feyd
Appropriate.. hmm... Is it actually an exceptional case?

Some programmers choose to use exceptions for all errors when calling a given method in languages supporting them. Do you feel you are one of these programmers?

Posted: Sun Mar 04, 2007 6:51 pm
by Ambush Commander
Appropriate.. hmm... Is it actually an exceptional case?
Yes. Errors usually are, right? :_)
Some programmers choose to use exceptions for all errors when calling a given method in languages supporting them. Do you feel you are one of these programmers?
Well, this'll be the first time I've ever used exceptions at all, so I don't think so. I might go that path though.

Posted: Sun Mar 04, 2007 9:34 pm
by feyd
Ambush Commander wrote:Yes. Errors usually are, right? :_)
In my experience, it's quite often that errors, especially those found in PHP, can be handled far more gracefully than KaBooM!

Simple things like out of bounds errors and such are better handled gracefully, I think. Information that isn't easily corrected, like when you expect an object to be filled when passed instead of empty or null, that's a possible exception point.

Posted: Sun Mar 04, 2007 11:16 pm
by Christopher
One reason that exceptions are for the exceptional is because they are designed to communicate failures that occur in one context or layer to another context or layer. Because of this distance there is usually not the ability to "handle" the error in the usual sense which would use all the information available in the current context -- a separate layer would know far less. Layers are not supposed to know intimate details about other layers (by design). Hence the usual limitation of exceptions use. If you are just dealing with things that you know can go wrong within a context, then you can usually handle it more elegantly usually normal constructs. So I think it is less about the type of error and more about the circumstance.

Posted: Mon Mar 05, 2007 2:02 pm
by Ambush Commander
Hmm... I think I get it. So what HTTP status code to throw is actually a choice made by the exception handler, when you end up with a truly fatal error. Alright. Makes sense.

Posted: Mon Mar 05, 2007 3:10 pm
by Begby
Ambush Commander wrote:Hmm... I think I get it. So what HTTP status code to throw is actually a choice made by the exception handler, when you end up with a truly fatal error. Alright. Makes sense.
No, what they are saying is that if you expect certain things to go wrong within a given context, then use something other than an exception. If its an error that occurs several layers away from your context, then use an exception.... for instance....


You have a page that grabs some information from $_POST then creates a query based on the information on it, then executes that query. Within that page you do some checks to make sure that you get the required information in the POST request and the information is valid. If for instance a name is left blank, the proper action is to redisplay the form and show an error saying that the user forgot to type their name.

The above all happens in one context, you have all the information in front of you and know where the data is coming from so you really don't need an exception.


Now from a different perspective, lets say you write you application using several layers, instead of creating a query right on the page, you encapsulate it into a reusable object.

Lets say you use this object in several ways, maybe get information from a form to insert a new record. Then at another spot get information from an XML import to insert a new record, and at another spot you access it with Ajax requests and use it to create new records.

Now within this object you create some error checking for the name field. Since the object is reused it will have no knowledge of what context its being used in. It doesn't know if its being called from your form input script, from an XML import, or from your ajax app. So in this case it should throw an exception.

It should be up to the other parts of the application that call the object to make sure that the information is complete and handle the problems gracefully, in this case the exceptions within the object are another level of checking to make sure that the code that uses the object is correct.

Since its an exception it can be handled different ways. You can make it throw an HTTP error, you can write it to a log, or you can display useful backtrace on your dev box. Its a ton easier to find a problem 3 levels deep within your code using an exception. However if all of your code happens within one page with no objects, then there is no reason to use exceptions.

Posted: Mon Mar 05, 2007 4:38 pm
by mikeq
Begby wrote: The above all happens in one context, you have all the information in front of you and know where the data is coming from so you really don't need an exception.
However, nothing wrong with using exceptions in this context either.

I come from a Delphi (Object Pascal) background and love the fact that Exceptions now exist in PHP, I would use them in this context.

Posted: Mon Mar 05, 2007 6:50 pm
by Ambush Commander
Ack, wrong train of thought.

What they were trying to say was that exceptions solve the problem of bubbling errors back up to higher level callees, who would know what to actually do the problem.

What I was thinking about when I wrote that half-assed comment was how HTTP error codes fit into an exception handling scheme. Sorry. :oops:

Posted: Tue Mar 06, 2007 9:49 am
by Jenk
Just a small blog about exceptions from my POV..

Exceptions are literally that. An exception to expected behaviour. If I know that a function such as mysql_query() will return either a result set, or false on error, I don't need to throw an exception, but one level up from that, where an object or function that has mysql_query embedded is designed to return a result set, but cannot because it retrieved "false" from the query, I would throw and exception to say "Hey! I have a problem here!"

In loose typed languages (ala PHP) they are not essential, but in strongly typed languages they are necessary.