[Pharo-project] Improving Pharo's Exception Hierarchy

Hernan Wilkinson hernan.wilkinson at 10pines.com
Thu Apr 14 16:39:53 CEST 2011

On Thu, Apr 14, 2011 at 5:33 AM, Toon Verwaest <toon.verwaest at gmail.com>wrote:

> Somehow I feel like I offended someone :)
> 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.
> 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 ;)

I think you said it right here: "having classes for all _relevant_ concepts
actually pays off"...
Related to exceptions, my question is:  what are all the different concepts
you have? for example, not finding a Key or not finding a Value are really
different concepts? or is it the same (not finding something) that depending
on the context (finding a value or a key) is what looks like they are
different? if so, then there is only one concept (i.e. not finding an
object), if it is a key or a value is accidental, contextual to what you are
looking for.
So, I completely agree when you say "having classes for all relevant
concepts"... I think we do not agree on what are the relevant concepts when
we talk about exceptions...

> Toon
> On 04/14/2011 01:00 AM, Dale Henrichs wrote:
>> On 04/13/2011 02:58 PM, Toon Verwaest wrote:
>>> Is it such a problem if you duplicate a certain exception class? At the
>>> moment you'll do the same anyway by not completely writing the exact
>>> same symbol.
>> It's a simple matter of namespaces and volume of names ... with a large
>> open ended namespace you are more likely to have a number of redundant names
>> with slight differences in spelling showing up in different spots in the
>> hierarchy...with a logically segmented namespace each segment will have a
>> manageable number of names and the risk of duplication is reduced ... end of
>> discussion ...
>> 10,000 names vs 30 names ... I can easily recognize duplicates in a list
>> of 30 names ... not so easy in 10,000 ... that is all ...
>> to attempt to map every possible error condition onto a class will lead
>> you to 10,000 much quicker than using reasonCodes ... that is all ...
>> I don't hate classes, it is a _practical_ matter ... if _you_ would rather
>> manage 10,000 names then I will say that it isn't practical ... I'm _not_
>> saying it is _wrong_, just not _practical_.
>>> And if the problem is not finding classes anymore, maybe we need a
>>> better way of organizing the exception classes away from the standard
>>> classes so that they are as non-intrusive as symbols, but convey more
>>> information?
>> And now you've hit the nail on the head ... in order to handle the extra
>> complexity you need additional tools ... before creating more tools, ask
>> your self the simple question: "Do I _need_ the additional complexity?" ...
>> if the answer is yes, then create the tool, if the answer is no, then you
>> don't need to create a new tool ..
>> Again, this is a _practical_ matter...
>>> self error: #keyNotFound
>>> does not really give much information; and isn't much more difficult to
>>> write than:
>>> KeyNotFoundException new in: self; key: key; signal
>> From a practical perspective how many exception handlers will be written
>> to handle KeyNotFoundException ... I use at:ifAbsent: when I'm doing a look
>> up that I think might fail ... better than writing an exception handler ...
>> If there is a real need to write a handler for KeyNotFoundException, then
>> by all means create the class, but until you actually NEED
>> KeyNotFoundException, `self error: #keyNotFound` or `NotFoundException
>> signal: #keyNotFound` will work just fine...
>>> although the second one gives you all the contextual information that
>>> the first one misses.
>> _If_ you NEED the additional contextual information. It's just like
>> writing a framework that no uses ... there's nothing wrong with the idea or
>> the implementation, it's just that the framework didn't solve a problem that
>> anyone had...
>> If you are going to create a class, I think the least it should do is
>> address an real problem, not an imaginary one.
>> To say that "if one were to handle the KeyNotFoundException, they will
>> need the complete context", I prefer to say "Until one needs the complete
>> context of the KeyNotFoundException, don't bother creating class"
>>> What I mean mostly: what about trying to figure out why you want to
>>> avoid decent exception classes and tackling that problem?
>> Depends upon what your definition of a decent exception classes is? My
>> argument is simply that it is not _necessary_ to create a unique class for
>> every unique error condition ... I think that folks should answer the
>> question: "Will anyone every write an exception handler for this exception"
>> before creating the class ... if the answer is yes (or better yet, I am
>> writing code right now and need that exception) then by all means create the
>> class.
>>  Maybe we don't want classes but exception objects that can pool data
>>> together? Maybe a very silly idea: what about just exception "classes"
>>> that have dictionaries to store enough information?
>> That would be another way of doing things ... although using exception
>> classes and reasonCodes is pretty close to all that is needed...
>> I agree with the notion that it isn't that useful to have a single Error
>> class and have all errors mapped to it ... on the other hand I don't think
>> it is particularly useful to have an exception class for every possible
>> error condition ... the compromise is to provide a smallish hierarchy of
>> excpetion classes with fairly general structure, provide a means for
>> uniquely identifying every possible error condition (I think that is
>> important) and then add new classes to the hierarchy when a demand for the
>> class is found ...

*Hernán Wilkinson
Agile Software Development, Teaching & Coaching
Mobile: +54 - 911 - 4470 - 7207
email: hernan.wilkinson at 10Pines.com
site: http://www.10Pines.com <http://www.10pines.com/>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20110414/97a3ce62/attachment.htm>

More information about the Pharo-project mailing list