I have a few questions for someone who has experience writing their own custom error handlers. What I want to do is create one class that handles all errors in the application. This will allow me a number of benefits:
- One central location to handle all errors
- Cleaner error handling code after each function call
- Ability to generate a MIME object (HTML, XML, PDF, Text, WAP) and return it to the client. This is typically an HTML error page, but I want to generate other types like WAP as well.
- Create global string tables that can be language translated in separate language files in a lookup table
- Create a central error code file that gathers all error codes in a lookup table
- Allows one to trigger_error(E_XXX) throughout their code.
Here's my questions:
1) Let's say that an expression has the error suppression operator @ in front of it. If that expression generates an error, does the custom error handler get that message? If so, how to detect? What is the appropriate behavior that should be taken in the custom error handler upon detection of a suppressed error message? Not take any action at all?
2) Is it correct to assume that the error_reporting() function holds the current state of the error mask that should be checked inside a custom error handler? That is, if E_USER_ERROR | E_USER_WARNING | E_USER_NOTICE bits are set by error_reporting(), that these bits are the only one's that should be handled by the custom error handler?
3) Given #2, what is the default behavior for error types that fall outside of what was set in error_reporting()? Should one call the old handler in those cases?
4) I've studied some of the zend.c source code and read some of the docs. It appears that many error bits do not even get sent to the custom error handler (like E_ERROR, E_PARSE, etc.).
In those cases, does the default error handler get these errors? Will the custom error handler ever see them at all?
4) In my error handler, I use E_USER_ERROR to denote critical errors. Should I do a die()/exit() in those cases?
5) Lastly, as I mentioned above, I want to be able to return a message formatted to the MIME type specified by the client. How do I determine what the type is the client is requesting in PHP? I assume it has to do with HTTP headers. After I determine this, I want to run this through an XSLT stylesheet catered to that type and generate the appropriate file in response back on error.
Sorry for all the questions. It appears to me that the only use of a custom error handler is to take over error handling for E_USER_XXX types of settings. By triggering via trigger_error($msg, E_USER_XXX), one can divert all error handling to once central location and deal with it there. All the other E_XXXX types are virtually ignored and one has no control over them as they go to the default error handler.
Note: I posted mistakingly in the newbie section, but this question should be more appropriate here.
