Exceptions as fatal http errors?

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Exceptions as fatal http errors?

Post 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?
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post 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?
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post 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.
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post 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.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post 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.
(#10850)
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post 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.
Begby
Forum Regular
Posts: 575
Joined: Wed Dec 13, 2006 10:28 am

Post 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.
User avatar
mikeq
Forum Regular
Posts: 512
Joined: Fri May 03, 2002 3:33 am
Location: Edinburgh, Scotland

Post 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.
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post 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:
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post 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.
Post Reply