|
This document describes the requirments of the exception service.
- Exceptions need to not require a base class
- Since exceptions are part of a classes interface, we can not
require that all exceptions subclass a particular framework exception.
- Standard Enterprise Information
- During the lifetime of a standard enterprise application it is quite
common to see hundreds of thousands of exceptions thrown. These
exceptions can range in cause from expected results to user mistakes to
major system failure. Creating a common cataloging standard for these
exceptions allows system managers to know which exceptions should be
logged, tracked and dealt with.
- Levelization is a good idea
- We should explicitly support levelization as it is the recommended
framework system
- Logging is good
- It is nice to automatically log exceptions since developers might forget.
We can send exception logs for all exceptions and then filter with
logging filters. That gives us the control to ignore or control this
situation.
- Extensibility is good
- Would we want to create a system that would allow generic extension of
exceptions. This might allow us to add functionality such as other types
of logging or notification. Or perhaps, logging could be added to
existing exceptions through this mechanism.
- Externalized Messaging
- We currently hard-code exception messages in the calls to exceptions and
once in a while place the messages directly into the exception class. Is
there a way to make them localizable, perhaps through extensible
exceptions. We could consider allowing even more information to
be included with exceptions (if it was externalized), such as
common causes and possible fixes to them.
|
