[Pharo-project] Improving Pharo's Exception Hierarchy

Dale Henrichs dhenrich at vmware.com
Wed Apr 13 23:33:36 CEST 2011


Nicolas,

Well put:)

Dale

On 04/13/2011 02:20 PM, Nicolas Cellier wrote:
> What's wrong is simple to explain: Your image is a namespace. The more
> names you have, the more difficult it is to apprehend, understand and
> reuse.
>
> Wait, wait, wait, you might say, whether I use Symbols or Class names,
> there are always the same number of names at the end.
>
> Yes, but what makes the big difference is the IDE. What we see thru
> this IDE is either:
> - a view by package or protocol
> - a hierarchical view.
>
> How to find if a specific Exception exists, what it's name is ?
> By now, I find package names misleading, because not very uniform.
> Even if uniformized, it's not always obvious where to search for.
> Plus, there are a lot of packages.
> The hierarchical view would be more natural, but is to my taste
> unusable above 30 items. I find current Exception hierarchy
> unfriendly.
> So the idea to use a double classification, a quite generic exception
> name like FileError and a specialization "code" does make sense.
>
> You must understand this, when our neurons were younger, we learnt
> Smalltalk with a ~300 classes image. What a great pleasure to be able
> to embrace the whole system !
> Now our older neurons must remember about 8x more...
> So we appreciate the inflation with a different scale.
>
> Nicolas
>
> 2011/4/13 Toon Verwaest<toon.verwaest at gmail.com>:
>> I find the "managing the exception hierarchy" a bit strange... Do you really
>> have to manage anything more than just normal classes? Every exception is
>> related to a specific part of your code, just like other classes. What's
>> wrong with creating hundreds of small classes wherever it's necessary? You
>> might save a tiny bit of memory by using error codes or symbols, but I don't
>> really see much more of a gain there, while you do gain from proper objects.
>>
>> Being clear and modeling properly generally pays off in the long run. And
>> the bit of runtime memory you save isn't really worth your while...
>>
>> Or am I missing something else? I didn't really follow the whole
>> conversation in-depth.
>>
>> cheers,
>> Toon
>>
>> On 04/13/2011 09:54 PM, Dale Henrichs wrote:
>>>
>>> Camillo,
>>>
>>> Hey, I _am_ old, but not _that_ old:) ... There are a couple of things
>>> that were invented in the Stone Age that have survived to today, so old
>>> ideas are not immediately bad, because they are old:)
>>>
>>> It feels like you are creating classes that are not much more than symbols
>>> ...
>>>
>>> I am not one to shy away from using classes when they are called for, but
>>> I am just making a practicality point ... we don't have a unique class for
>>> each character in the alphabet, but we could....we could have a unique class
>>> for every possible error condition or not ...
>>>
>>> I think it is simply a practical answer...
>>>
>>> I do maintain that you _should_ use some sort of test along the lines of:
>>> "Will anyone ever need to write a handler for the exception?" in your
>>> criteria for deciding when to create a class and when to use something like
>>> a "reason code" to disambiguate the signalling site...
>>>
>>> Dale
>>>
>>> On 04/13/2011 12:32 PM, Camillo Bruni wrote:
>>>>
>>>> Perfect, I ll be there to bang heads ;).
>>>>
>>>> So without "Exception" pre- or suffix seems to be nice. However I
>>>> don't see the need of using symbols over real classes. This feels
>>>> indeed like going to stone age of error handling, thats what you have
>>>> polymorphism and ExceptionSets for.
>>>>
>>>> Anyway, the main idea is to make single exceptions recognizable and
>>>> not just use one single, basically meaningless, exception type.
>>>>
>>>> best regards, Camillo Bruni
>>>>
>>>>
>>>> On 2011-04-13, at 21:22, Sven Van Caekenberghe wrote:
>>>>
>>>>> Thanks a lot everybody for the reactions, this could become a nice
>>>>> discussion next Friday. All points raised are valid, I would like
>>>>> simple names and a compact multipurpose hierarchy too.
>>>>>
>>>>> On 13 Apr 2011, at 19:39, Dale Henrichs wrote:
>>>>>
>>>>>> Some thoughts from an old man (started programming before
>>>>>> exceptions of any kind were available:) ...
>>>>>>
>>>>>> In the old days, error numbers had a place in the universe ...
>>>>>> error numbers of a certain range indicated specific errors and
>>>>>> the "error handlers" could check for a range or a specific error
>>>>>> ...
>>>>>>
>>>>>> Today I think there is still a place for the notion of "error
>>>>>> numbers".
>>>>>>
>>>>>> In Smalltalk I would use Symbols instead of numbers, but the idea
>>>>>> would be to use a concrete exception class to identify broad
>>>>>> categories of error conditions (i.e., FileStreamError) and a
>>>>>> symbolic "reason code" to indicate the specific error (i.e.,
>>>>>> #fileDoesNotExist, #fileExists, #cannotDelete, etc.), that way an
>>>>>> error handler can be written for FileStreamError and then
>>>>>> specific action take with respect to which "reason code" is
>>>>>> involved, if such action is needed.
>>>>>>
>>>>>> The main advantage of using reasonCodes over using a "class per
>>>>>> error condition" is that you can reduce the size of the Exception
>>>>>> hierarchy to a manageable size (GemStone has hundreds of error
>>>>>> conditions, so we've resorted to using "reason codes" to manage
>>>>>> the size of the hierarchy).
>>>>>>
>>>>>> As Hernan hints, more often than not it is important to be very
>>>>>> specific about the error condition when signalling an error (a
>>>>>> unique error message per "per reason code" would be desirable),
>>>>>> but the there are very few places where the handler is going to
>>>>>> be that specific ...
>>>>>>
>>>>>> In other words, if it is likely that programmers in the course of
>>>>>> using an application will be writing specific error handlers to
>>>>>> distinguish between the KeyNotFound and ValueNotFound condition,
>>>>>> then classes should be created, otherwise, the NotFoundException
>>>>>> could be implemented with three reason codes: #keyNotFound,
>>>>>> #valueNotFound, and #elementNotFound and you'd get the best of
>>>>>> both worlds, explicit information at the signalling site and a
>>>>>> much smaller and more manageable Exception class hierarchy.
>>>>>>
>>>>>> Dale
>>>>>>
>>>>>> On 04/13/2011 10:15 AM, Hernan Wilkinson wrote:
>>>>>>>
>>>>>>> I think it is not a good idea to use the prefix Exception. We
>>>>>>> do not use the word "exception" in real life, so we should not
>>>>>>> do it on our systems. About the proposed hierarchy, the problem
>>>>>>> with having specific exceptions is that they are important for
>>>>>>> those who catch them, not for those who signal them. For
>>>>>>> example, besides the name, what is the difference between
>>>>>>> KeyNotFound or ValueNotFound? none. So, I think that the
>>>>>>> exception hierarchy should be grown from it uses, not created
>>>>>>> based on how or where they are signaled.
>>>>>>>
>>>>>>> my 2 cents :-)
>>>>>>>
>>>>>>> On Wed, Apr 13, 2011 at 1:55 PM, Miguel
>>>>>>> Cobá<miguel.coba at gmail.com<mailto:miguel.coba at gmail.com>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> El mié, 13-04-2011 a las 14:52 +0200, Camillo Bruni escribió:
>>>>>>>
>>>>>>>> And as Mariano pointed out, there should be a convention on
>>>>>>>> the naming: I am still not sure about suffixing the exception
>>>>>>>> classes
>>>>>>>
>>>>>>> with
>>>>>>>>
>>>>>>>> "Exception", but I guess this is a good thing to do. Though
>>>>>>>> I
>>>>>>>
>>>>>>> must say
>>>>>>>>
>>>>>>>> that I omitted it so far ;) and just put the verb there, but
>>>>>>>> that can be easily changed.
>>>>>>>
>>>>>>> I would say no to suffixes. Analogous to announcements, they
>>>>>>> shouldn't have the suffix. The name should be descriptive
>>>>>>> enough and intention revealing that the suffix isn't needed in
>>>>>>> most cases. For example, I think that
>>>>>>>
>>>>>>> DividedByZero
>>>>>>>
>>>>>>> is better than
>>>>>>>
>>>>>>> DividedByZeroException
>>>>>>>
>>>>>>> and no information is lost with the sorter name. Instead,
>>>>>>> DivideByZero isn't clear enough to indicate that is a event
>>>>>>> that happened.
>>>>>>>
>>>>>>> What do you think?
>>>>>>>
>>>>>>> -- Miguel Cobá http://twitter.com/MiguelCobaMtz
>>>>>>> http://miguel.leugim.com.mx
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -- *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/>*
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>




More information about the Pharo-project mailing list