[Pharo-project] Improving Pharo's Exception Hierarchy

Dale Henrichs 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
> insight.
> 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
      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
   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 
waving arm:)...


More information about the Pharo-project mailing list