[Pharo-project] Improving Pharo's Exception Hierarchy

Dale Henrichs dhenrich at vmware.com
Wed Apr 13 21:54:08 CEST 2011


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


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