PHP Error handling

Question

Thank you one and all ahead of time.

I am currently in the process of tweaking/improving a MVC framework I wrote from scratch for my company. It is relatively new, so it is certainly incomplete. I need to incorporate error handling into the framework (everything should have access to error handling) and it should be able to handle different types and levels of errors (User errors and Framework errors). My question is what is the best way and best mechanism to do this? I know of PHP 5 exception handling and PEAR's different error mechanism, but I have never used any of them. I need something efficient and easy to use.

Would it be better to create my own error handling or use something already made? Any suggestions, tips, questions are certainly welcomed. I would ultimately think it sweetness to somehow register the error handler with PHP so that I would just need to throw the error and then decide what to do with it and whether to continue.

EDIT: Sorry, I should of provided a more details about what type of errors I wanted to log. I am looking to log 2 main types of errors: User and Framework.

For user errors, I mean things like bad urls (404), illegal access to restricted pages, etc. I know I could just reroute to the home page or just blurt out a JavaScript dialog box, but I want to be able to elegently handle these errors and add more user errors as they become evident.

By Framework errors I means things like cannot connect to the database, someone deleted a database table on accident or deleted a file somehow, etc.

Also, I will take care of development and live server handling.

Answer 1

I would ultimately think it sweetness to somehow register the error handler with PHP so that I would just need to throw the error and then decide what to do with it and whether to continue.

You can do exactly that, with set_error_handler() and set_exception_handler().

There is no "one right way" to do error handling, but here are some things to consider.

• trigger_error() is similar to throw new Exception in that they both escape out of the current execution immediately, only trigger_error() is not catchable.
• How do you want errors handled on a dev environment (show on screen?) versus in a production environment (logged and emailed?)
• You can use the above functions to essentially "convert" errors into exceptions, or vice versa
• Not all error types can be handled with a custom error handler

Answer 2

Here's some things that I usually do:

• Use a global configuration setting or flag to switch between development and production.
• Don't use php errors when you have a choice: Prefer exceptions for your own error handeling. If you're using a library that doesn't use exceptions, detect the errors and throw your own exceptions.
• Use a top level exception catcher that displays exceptions in a way that's easy to read. If you place this try-catch-block strategically, you don't have to register a global exception handler.
• Always develop with error_handeling(E_ALL | E_STRICT)
• Catch PHP warnings and notices using set_error_handler(), and halt execution. This elimates a lot of bugs in advance, with very solid code as a result.
• The global error handeling code should be very light-weight, in order to avoid errors. There's always a risk for recursion when dealing with global error handlers.
• If the system is in production mode, don't display any details: Log the error, and generate a unique identifier that the user can refer to if they want to file a bug or report the error.

Answer 3

When working on a larger site, its better to have an understanding of the history of errors, especially when things can pretty easily cascade into unintended logic paths when a tester or a user triggers a weird use case.

I tend to build in try catch blocks that are capable of both logging the error and halting execution in the case of something fatal (and spitting out a forward facing error page with the error code), or in the case of a soft error, continuing on, but noting it in my error logs. Mostly end up building a custom error handler, since I find there is just too much nuance otherwise, as you scale up.

During development, I use Particletree's PHP profiler to log errors and other relevant data to a console with the trace, message, and line. It is just pretty -- can't speak to its efficiency. It can bloat the code, but oh my good god, it can be a life saver to have a plain text understanding of where and how errors occured. Especially helpful when dealing with things like SOAP web services that will throw exceptions at you like nobody's businsess.

I also find it useful to abstract a Debugging log, and keep it global, such that as people have said before, when you switch to production, you aren't spitting all kind of dirty laundry out into the cold internet air, since you can relatively easily change the output of the debugger to a sql database, or email, or whatever.

Particletree's Profiler: http://particletree.com/features/php-quick-profiler/

Answer 4

Before going live I test my project completely at key stages during development, checking my error logs (I use Plesk control panel) to track php errors.

When a project is live, at key stages in a class or application I send an error or debug report using a class I built. It sends the error report to a defined email address with key info such as: datetime, user ip, referring page, full url and a short note that I define when triggering/calling the debug class.

I use to force it to write a log file, but found this both insecure, as the directory had to have a chmod of 777, and not efficient as I had to access the latest logs each time. By emailing them to me I action the problem straight away.