> Note that if PDOExceptionHandler woudln't exist, ErrorHandler would > handle the exception. (we need to determine what to do by default)
I like this for specific exceptions that we don't want to expose (like the one you mention). I've successfully used a design like the following, in the past: HabariException - a base exception class; could be abstract. This class exists only so we can "catch (HabariException $e)" and exceptions that are from (e.g.) PDO, would trickle up to the PDO exception handler. HabariCriticalException - an exception that is caused by a fundamental error in the system or code, such as improperly calling a method, or inability to connect to a database. Because this class of exception stems from an implementation/system error (and not from the end user), it is irrecoverable (it can be caught, but for the most part shouldn't be caught for the purposes of muting) HabariInputException - this is caused by user behaviour. It is thrown when input from the user causes some sort of error. It contains a "subject" member with accessor methods so that the calling code can catch it and easily determine exactly where the exception occurred (something like ->subject = 'name'; if a user supplies an invalid name) HabariInputMultiException - this is a wrapper exception that can contain multiple HabariInputExceptions (so full forms can be validated without multiple reloads) HabariAuthException - due to lack of permissions or failed authentication We could also add plugin/theme-specific exceptions, I think. Exceptions during Ajax calls trickle up to the controller, and are wrapped in an envelope that makes them easy to check. Thoughts? S --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
