[Pharo-project] Improving Pharo's Exception Hierarchy

Hernan Wilkinson hernan.wilkinson at 10pines.com
Wed Apr 13 22:30:14 CEST 2011


I completely agree with what Dale is saying... if you look at Patagonia (is
on squeak source) you will see a package call Patagonia-AssertionsModel
where I use something similar (if not the same) as Dale is saying... That
package reifies different types of assertions, but when an assertion fails,
it only throws one exception... the problem is how to handle an specific
assertion failure?... if you look at the method #asExceptionToHandle you
will get it, but basically from the handler point of view you write:

[ bla bla bla ]
  on: #earlyRegistrationFeeShouldBeLessThanLateRegistrationFee
asExceptionToHandle
  do: [ :anAssertionFailure  | .... ]

Doing so the exception hierarchy is really simple. But each assertion has a
name (what Dale calls "error numbers" at the begining) so the assertion
failure (the exception) knows the assertion that failed and therefore it can
be identified by the assertion's name, and you don't need to have a class
per exception.... (the cool thing is that the name of an assertion is
automatically set with the name of the method you are creating the assertion
in, hehe, so if you rename the "helper" method where you create the
assertion, the rename refactoring takes care of renaming all the places
where it is handle :-) )

Anyway, being able to extend the exception mechanism with this is another
reason why Smalltalk will never die :-)


On Wed, Apr 13, 2011 at 2:39 PM, Dale Henrichs <dhenrich at vmware.com> 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/>*
>>
>>
>


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


More information about the Pharo-project mailing list