El jue, 14-04-2011 a las 08:50 -0700, Dale Henrichs escribió: > For the Exception framework I think the following guidelines should apply: > > 1. Each unique error _should_ be uniquely identified and the current > mechanism of providing a string argument to the #error: message is > not sufficient. > 2. Specific handlers will not be written for most errors, so it isn't > absolutely necessary to create a unique exception class for all > errors > 3. If specific handlers exist (doing string parsing now) or there is a > reasonable case made that specific handlers are likely to written, > then a unique exception class should be created. > 4. reasonCodes (within the namespace of an exception class or > subhierarcy) can be used to uniquely identify an error condition, > when a unique class isn't called for. > 5. In the fullness of time, if a case is found where a reasonCode > should be turned into a unique exception class, then the class > should be created. > > These guidelines should help keep the Exception hierarchy as small as is > needed, but allow expansion as well. > > Keep in mind that the primary purpose of the Exception is to allow code > to be written that automates the handling of the exception. Developers > don't need Exceptions to debug/develop applications ... the debugger > provides all of the information that a developer needs ...So the > exception is there when a developer cannot look at the stack and must > write code to report the error to a log, an end user, or take corrective > action .... for an error report, the exception class and reasonCode is > sufficient information for a developer to go back to the code and > determine the call site ... >
Very well put. I think that those guidelines will permit to evolve the current Exception framework in Pharo and avoid ending with an over-engineered and commite-dictated set of seldom used exception classes. Thanks Dale -- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
