Question

I have an application which relies on a soap server to produce content. Additionally authentication to the site is based on a separate LDAP server. Obviously if either of these are down or not responding the site is down.

I am trying to lay out a design such that I can have error reporting for site admins and also give a nice message to user’s in the case that the site is down. Error reporting is really just an email, database insert or log to text file on server of PHPs $_COOKIE, $_SERVER, $_SESSION, $_REQUEST along with potentially a SoapFault exception. This information would aid me in debugging any potential problems with the site if they occur.

Currently, my site is designed as follows:

SoapClientInterface (defines soap functionality)
      / \
       |
       |   implements
       |
Client (the client implementing the interface, try/catch blocks on all soap calls here) 
      / \
       |
       |  extends
       |
 Authorization (asserts soap objects returned from server/ requests going to server 
               are appropriate for the user performing the request) 
      / \
       |
       | extends
       | 
  {all children classes using the soap interface defined on this level} 

From the poor diagram above 🙂 I have a class Client which encompasses all of my try catch blocks for soapfault exceptions and am wondering the best way to do two things with the catchs:
1. notify user an action has failed (all of my functionality is in if/else blocks and if I determine an operation has failed I re-direct user to a status page and inform them that their action has failed.
2. report the situation to site admins for debugging (this functionality at the moment is a simple function defined in status page that when status page gets an error code we dump the Cookier, Server, Session, and Request variables and email this off to site admins.

Any suggestions on this would be appreciated or if you need clarification please ask.

EDIT: In my experience with web programming my applications usually display status of user actions on the page in which the action takes place and do not re-direct elsewhere. This is the first time I have coded an application to perform a user action and redirect to a separate page for all status messages. Should I be kicking myself for doing it this way, does anyone see merit in having a single status page for all site actions or having a class/function that reports status on the page in which the action took place? (I am asking this in regards to thinking about the design of status page on its own and how to report errors and what not.)

Answer 1

Well, personally I think it depends on the error. In my experience, there are three types of exceptions. Those that you can ignore, those that you can work around, and those that you use to terminate execution (A file_not_found exception can be ignored if you’re just trying to delete the file, a resource_not_available exception may be able to be worked around if there are alternative sources for the resource, and a database_connection_failure exception would require termination of the app unless you had a backup)… Which type of exception was caught will dictate what you do with it.

Personally, I install a global exception handler… Then, in my catch block I can choose whether to clean up the request, handle it differently, continue on (if it’s a recoverable exception), or re-throw the exception if I can’t handle it properly (Query error, etc). If the exception makes it to the top of the stack (the global handler), then I log the error (I use a database table for this) and throw a 500 internal server error.

As far as redirecting for errors, I can’t stand that. If the error is a temporal error, then why can’t I just refresh the page? Why must I go back (if I even can) to try again…

As long as you output buffer properly, you should almost always be able to render an error page without displaying any sensitive info to the user (I say almost, since you can’t render anything for a fatal error)… Otherwise you’re breaking HTTP spec (Since you are saying there’s a temporary redirect from the current page where the error occurred rather than the proper "an error occurred" status header)…