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