[Pharo-project] Improving Pharo's Exception Hierarchy

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

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

> Right, so you confirm the experience of Dale.
> In the case of flagging errors without classes, do you generally just use a
> simple symbol, or concatenate strings to convey more details? This last
> seems somehow a bad idea... but maybe if it's never caught it's not so
> relevant?

I don't understand exactly what you mean... if you are suggesting using
error codes over exceptions, no, that is not may point. Exceptions are the
right tool to get rid of the repeated/error prone code you create when using
error codes, there is not doubt about it.
What I'm saying is that from the handling point of view you only need to
identify the exception to handle, and matching the class of the exception
with identifying the exception is not the only way (I showed another way in
a previous mail).
Also, categorizing exception types using subclassing does not seem to be a
good idea either... it is common use now, but that does not mean it is good.
Sometimes you want to categorize exceptions in a different way that your
exception class hierarchy forces you, and when that happens it is really a

> cheers,
> Toon
> On 04/14/2011 02:03 PM, Hernan Wilkinson wrote:
>> the problem is not related to technical issues (like how much machine
>> memory you save, etc). It is related to knowledge organization...
>> If you have two classes that define exactly the same methods, inst var,
>> etc, why do you have two instead of one? If you answer is "because of the
>> name of the class", remember that names are contextualized to the place
>> where they are used...
>> I mean, this is easy, just take all the places where exceptions are handle
>> in Smalltalk and look what the handlers do with the exceptions. You will see
>> that in almost all cases the exceptions are not used at all, the information
>> they carry with them is not use at all... so, from a theory point of view it
>> looks nice to have a big exception hierarchy but from the practical point of
>> view is not only useless but also more difficult to use.
>> I build a system that had an exception class base on where they were
>> signal and not handled, we end up with around 1100 exceptions... only 3 or 4
>> are handled directly

*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/a7970a91/attachment.htm>

More information about the Pharo-project mailing list