Error handling on PHP website

Question

Can someone guide me in the right direction on how to implement and at what stage should i add in the error handling code?

Website:
social network like linkedin. Platform is MySql and codeignitor PHP. Requirement: 3 cases for errors:

1. Front end like http codes. In this case user is redirected to a std message page. Nothing to capture at DB.

2. Second case is the back end errors like if server takes too long, error writing to DB, other DB issues, code blowups etc. Expected is the user in all these cases will only see an error message box that "someone has been notified, try again later". Similar to how it is on facebook except facebook has different error text based on error type.

3. 3rd error type is session related: Cookies getting disrupted during a session and timeouts occuring in which case display a please login message window.

My question is now:

1. To capture all various errors that fall within case 2, can it be done at the same time development is in progress or do the developers have to go back and add in the error catching at end of project at each entry point in code which could be millions of lines of code?

2. My team is telling me they don't know all possible cases that an error can occur within case 2 until entire development is complete. But i argue that error hadling code is general no matter what. Only addition to code is an error catching clause for the error category we want to capture and the error message to dislay if different which can be added at any time but the underlying error code is same so it can be written even before development starts?

3. How do I find all the possible or catch for all possible cases an error can occur in case 2 which there can be hundreds of usecases of something blowing up at any level or DB read/write errors, etc. Do we need separate code for each or a common code catching all?

My developers are new too and so am I so I dont think anyone is exactly sure on when and how to approach the error handling on the site. On the backend of system when an error occurs an email will be sent to admin and I am building an error tracking system so we can keeptrack of issues in the backend automatic with status, type, notes, etc.

Answer 1

1. Appropriate error pages should be provided for the the HTTP errors you expect to be generating. These pages should provide minimal data as to what the error is, and indicate appropriate retry/follow-up actions for the user. One more more links back to safe areas are often appropriate.
2. The full list will become known as development progresses. This is normal for any construction process. Any actions which can not be corrected within the code should be handled by your page generation code. These may be handled by logging and generating an appropriate HTTP error page (already done in handling 1.). Handling the error by class rather than specific error conditions would be appropriate. The actual error condition should not be reported to the user unless the user can correct it themselves.
3. Use common catch code for all errors and respond by error class. In many/most cases you will want to generate a stack trace in an error log. Generate the appropriate HTTP error code for display. Review the HTTP specification for the appropriate HTTP responses to use.
4. Form validation is a separate category and should be handled appropriately during verification of input. This should result in redisplay of the page with appropriate error messages embedded.

Answer 2

1.To capture all various errors that fall within case 2, can it be done at the same time development is in progress or do the developers have to go back and add in the error catching at end of project at each entry point in code which could be millions of lines of code?

Both, but generally just needed while development is in progress. It's actually crucial to consider what types of errors each line of code could produce on its own (especially if grabbing data from external or DB sources), so you need to account for all that at each step. To help insert special case handling after everything is already in place, this is where a master error handling function comes into play. Just take note of what error levels will never even trigger your custom error handling. You may also be interested in the Exception class. Again, to allow for easier inserting of special case handling by only having to make updates in fewer spots, extend the Exception class into your own special error object.

2.My team is telling me they don't know all possible cases that an error can occur within case 2 until entire development is complete. But i argue that error hadling code is general no matter what. Only addition to code is an error catching clause for the error category we want to capture and the error message to dislay if different which can be added at any time but the underlying error code is same so it can be written even before development starts?

Kind of the same question as #1. IMHO, you are correct. And in some cases, so are they. One developer really can't know what types of errors another developer's code would generate until they see the code or get a hold of its final documentation.

3.How do I find all the possible or catch for all possible cases an error can occur in case 2 which there can be hundreds of usecases of something blowing up at any level or DB read/write errors, etc. Do we need separate code for each or a common code catching all?

Again going off question #1, using custom error handling functions or extending off the Exception class (even making separate classes for handling DB try/catches vs file access try/catches, etc), this should help significantly. Say you discover a new possible error your DB could spit out. If you already have the connect and query functions wrapped in try/catch blocks, you need only add the handling script in your extended Exception class, and not wherever your DB functions exist. For example, you may opt to just do something like this for all your db connects. DB_Exception in this cases is your extended version of Exception, which could itself do any number of troubleshooting tasks on its own:

function db_connect() {
    $MySQLi = new mysqli(DB_HOST, DB_USERNAME, DB_PW, DB_NAME, DB_PORT, DB_SOCKET);
    if ($MySQLi->connect_error) throw new DB_Exception($MySQLi->connect_error);
    if ($MySQLi->error) throw new DB_Exception($MySQLi->error);
    return $MySQLi;
    }

try {$MySQLi = db_connect();}
catch (DB_Exception $e) {if (!$e->is_fixed_now) die($e->special_message);}

You could also have your extended Exception class reference a set of canned responses enumerated by the $code construct argument. But, you really should not try to apply special error handling to every conceivable DB error you may get. It's much more efficient and way less a burden to most of the time just grab the MySQL error text whatever it may be and forward that to your admins.

As for the text you display to the user, it's best to always keep it simple and informative while giving absolutely nothing away about the inner workings of your website. Example: your DB server crashes or someone mistakenly misset file permissions: all you should tell the user is "Sorry, technical difficulties, this particular content is not available just now, our staff has been notified, please try again later. If urgent email so@so.com or call support at 555-1212.". You could also do the canned message based off the Exception $code argument, same as above, but give nothing that will help in the event of a site attack.

Also, "On the backend of system when an error occurs an email will be sent to admin" Not actually a good idea. The user may just sit there hitting refresh over and over until it magically starts working again. You could easily be caught in an email storm. One possible solution is to run a 10-minute cron job checking to see if the error log has been modified in the last 10 minutes, and email a summary of new log entries instead. Or, if you have a trouble ticket system, have the error script open one only if an open ticket on the topic doesn't exist.