How to design error reporting in PHP

Question

How should I write error reporting modules in PHP? Say, I want to write a function in PHP: 'bool isDuplicateEmail($email)'. In that function, I want to check if the $email is already present in the database. It will return 'true', if exists. Else 'false'.

Now, the query execution can also fail, In that time I want to report 'Internal Error' to the user.

The function should not die with typical mysql error: die(mysql_error(). My web app has two interfaces: browser and email(You can perform certain actions by sending an email). In both cases it should report error in good aesthetic. Do I really have to use exception handling for this?

Can anyone point me to some good PHP project where I can learn how to design robust PHP web-app?

Answer 1

Using MVC, i always use some sort of default error/exception handler, where actions with exceptions (and no own error-/exceptionhandling) will be caught.
There you could decide to answer via email or browser-response, and it will always have the same look :)

Answer 2

I'd use a framework like Zend Framework that has a thorough exception handling mechanism built all through it.

Answer 3

Look into exception handling and error handling in the php manual. Also read the comments at the bottom, very useful.

There's aslo a method explained in those page how to convert PHP errors into exceptions, so you only deal with exceptions (for the most part).

Answer 4

In my PHP projects, I have tried several different tacts. I've come to the following solution which seems to work well for me:

First, any major PHP application I write has some sort of central singleton that manages application-level data and behaviors. The "Application" object. I mention that here because I use this object to collect generated feedback from every other module. The rendering module can query the application object for the feedback it deems should be displayed to the user.

On a lower-level, every class is derived from some base class that contains error management methods. For example an "AddError(code,string,global)" and "GetErrors()" and "ClearErrors". The "AddError" method does two things: stores a local copy of that error in an instance-specific array for that object and (optionally) notifies the application object of this error ("global" is a boolean) which then stores that error for future use in rendering.

So now here's how it works in practice:

Note that 'Object' defines the following methods: AddError ClearErrors GetErrorCodes GetErrorsAsStrings GetErrorCount and maybe HasError for convenience

// $GLOBALS['app'] = new Application();

class MyObject extends Object
{
     /**
      * @return bool Returns false if failed
      */
     public function DoThing()
     {
          $this->ClearErrors();
          if ([something succeeded])
          {
              return true;
          }
          else 
          {
              $this->AddError(ERR_OP_FAILED,"Thing could not be done");
              return false;
          }              
     }
}

$ob = new MyObject();
if ($ob->DoThing()) 
{
   echo 'Success.';
}
else 
{
   // Right now, i may not really care *why* it didn't work (the user
   // may want to know about the problem, though (see below).
   $ob->TrySomethingElse();
}

// ...LATER ON IN THE RENDERING MODULE
echo implode('<br/>',$GLOBALS['app']->GetErrorsAsStrings());

The reason I like this is because:

1. I hate exceptions because I personally believe they make code more convoluted that it needs to be
2. Sometimes you just need to know that a function succeeded or failed and not exactly what went wrong
3. A lot of times you don't need a specific error code but you need a specific error string and you don't want to create an error code for every single possible error condition. Sometimes you really just want to use an "opfailed" code but go into some detail for the user's sake in the string itself. This allows for that flexibility
4. Having two error collection locations (the local level for use by the calling algorithm and global level for use by rendering modules for telling the user about them) has really worked for me to give each functional area exactly what it needs to get things done.