[Pharo-project] Improving Pharo's Exception Hierarchy

Dale Henrichs dhenrich at vmware.com
Thu Apr 14 01:00:11 CEST 2011

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 ...

More information about the Pharo-project mailing list