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
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 ...
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:)...
Dale
