[Pharo-project] Improving Pharo's Exception Hierarchy
dhenrich at vmware.com
Thu Apr 14 17:50:34 CEST 2011
On 04/14/2011 01:33 AM, Toon Verwaest wrote:
> Somehow I feel like I offended someone :)
Not at all ... I like to wave my arms, talk passionately and draw all
over a white board ... all things that are difficult to do in an email:)
> I personally don't have experience with 10'000+ classes in a system. I
> do understand that's where you are coming from and do appreciate the
> My personal experience has rather been the opposite until now. For
> example the Pharo/Squeak classbuilder is 1 single class doing
> everything. This is horrible; not just horrible because the code is
> completely horrid but it's non-extensible, non-configurable,
> non-reusable, contains tons of duplication _just because_ it is all put
> into one big ball of mud. By decomposing the classbuilder into 4 to 10
> different classes I ended up having very little methods with very little
> code, and a very high level of configurability and understandability. I
> now actually use this classbuilder to build anonymous classes too,
> avoiding the whole problem with forgetting to copy in the format that
> everyone seems to have.
Monolithic classes are difficult to maintain and hard to extend ... I am
whole heartedly in favor of using classes, just take a look at
Metacello: ~300 classes including a dozen exception classes.
My main message is that it is generally a bad idea to build a framework
when one isn't needed.
One shouldn't be shy about creating multiple classes to do a job, when
they are called for.
On the other hand, one shouldn't create a framework of classes until
such a frame work is called for.
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
2. Specific handlers will not be written for most errors, so it isn't
absolutely necessary to create a unique exception class for all
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 ...
> And this experience was showing me that having classes for all
> _relevant_ concepts actually pays off in the long run. Since you (and
> others) are saying that it doesn't for exceptions; and since I don't
> have enough experience there I'll take your advice into account when
> writing code ;)
Agreed 100% ... we all have to use judgment when writing our code, so
having a little more information never hurts (unless you're wacked by a
More information about the Pharo-project