Hopefully, to help clarify the process: http://andrewdasilva.com/incubator/ErrorEx1.png
The exception thrown was a PDOException code 1045. The PDOExceptionHandler did a custom handling and called MySQLExceptionHandler to let it handle the error code. Since 1045 is a bad credential, to reduce security threat we censure the [EMAIL PROTECTED] and file path. This is one example where custom handlers can be useful for either security censuring or recovering. Note that if PDOExceptionHandler woudln't exist, ErrorHandler would handle the exception. (we need to determine what to do by default) On Sep 15, 10:38 pm, Andrew da Silva <[EMAIL PROTECTED]> wrote: > In an effort to finally have a discussion on error handling, I present > you a series of questions and suggestions based on various readings. > As a disclaimer, this is in no way a formal suggestion since I am not > an expert but only the messenger. Please suggest your own concepts or > designs on how we should handle errors in Habari. > > Questions > - Do we want to use severity? (ErrorException object) > - If yes, do we want to support nesting of exceptions to build higher > severity exceptions? > - Do we want HTML in _core_ error handle? > - Should we keep an in-file revision number for debug information? > > Suggested Guidelines > - Error handling classes must be independent of other classes. > - Create an error description template. > - Document exceptions using phpDoc @throws. > - No more white pages!!! > - For backward-compatibility, we can’t change error handling method > names or inheritance (e.g, Exception rather than DBException) > > Error Object > - Can derive more specialized error classes from it. (per plugin to > support custom error handlers - e.g, ThemeError, ThemeException, > PluginError, PluginException) > - Extend with special methods to convert an instance to a string. > - Encapsulate the following data: line number, method name, class > name, file name, revision and error description. (most already > available in an Exception/ErrorException object) > - Add the methods: addUserInfo() and getUserInfo(). > > LogEntry Object > - Logs the Error Object. > > Error Handler > - Uses Error to display error messages. > - Uses LogEntry to log error messages. > - Provide a default error handler. (to define, default behavior) > - Configurable: handling modes (return, print, die, etc.), etc. > > Suggested Design: > 1. Throw ErrorException/[Custom]Exception with message template. > 2. On object creation, LogEntry logs the error message accordingly. > 3. The Exception is passes through the chain of error handlers, > ErrorHandler for unhandled exceptions. > 4. ErrorHandler, depending on handling mode prints, dies, etc. (could > call a filter hook) > 5. If ErrorHandler is in returns, caller handles the error and can > recover. (custom handlers could recover) --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/habari-dev -~----------~----~----~----~------~----~------~--~---
