On Fri, Oct 7, 2011 at 12:41 PM, Igor Stasenko <siguctua@gmail.com> wrote:

On 7 October 2011 13:53, Hernan Wilkinson <hernan.wilkinson@10pines.com> wrote:
> Or remove the absurd coupling between subclassing and grouping
> exceptions/events (or whatever name you prefer to use :-) ) that leads to
> absurd/depth/big exception/events hierarchies :-)

By proposing that, i expect that you have an alternative in mind. How
else you could
provide a grouping for exceptions/events in that case?

yeah yeah... of course :-) ... you could create any group you want with any collection and not only groups created by a "hierarchy".

So, you could create an ExceptionToCollectionAdapter that responds to #handles: answering true if the exception is included in the group you defined. For example:

ExceptionToCollectionAdapter class>>for: aCollectionOfExceptions

^self new initializeFor: aCollectionOfExceptions

ExceptionToCollectionAdapter>>initializeFor: aCollectionOfExcpetions

exceptions := aCollectionOfExceptions

ExceptionToCollectionAdapter>>handles: anException

^excpetions includes: anException

Therefor now you can:

[ ... bla bla ]�

� on: (ExceptionToCollectionAdapter for: (Set with: exc1 with: exc2 with: etc))

� do: [ bla bla ]

I used a similar technique to be able to easily identify different exceptions that are instances of the same class.�

For example, I created a model to easily run preconditions and if a precondition does not hold the exception AssertionFailed is signaled. So, to handle a particular assertion failure I use the name of the assertion in the #on:do:. For example.

Number>>/ aDivisor

� �"I removed the precondtions objects to make it easier for the example"

� �aDivisor = 0 ifTrue: [ AssertionFailed signalNamed: #divisorCanNotBeZero ].

� �bla bla

and now, to handle that assertion failure:

[ 1/0 ]

� on: #divisorCanNotBeZero asExceptionToHandle

� do: [ .... ]

Anyway, the magic again is the dinamic and open nature of smalltalk... in this case any object that anwers #handles: can be a parameter in the on: of the on:do:...�

It is very interesiting to show this example to Java, C# programmers, etc. �because it breaks the myth about exceptions and shows that exceptions is just another model and that in a good language you should be able to change it if you wanted :-)... so, GO SMALLTALK!!! :-)

Basically, what we need is a fast way to check if given object belongs
to some specific group (in case if we want to react on all
exception/events
in given group).
So?

>
> On Thu, Oct 6, 2011 at 12:49 PM, Lukas Renggli <renggli@gmail.com> wrote:
>>
>> On 6 October 2011 17:40, Igor Stasenko <siguctua@gmail.com> wrote:
>> > On 6 October 2011 17:24, Lukas Renggli <renggli@gmail.com> wrote:
>> >>>> why wasting an energy on something, which not gives any benefits?
>> >>>
>> >>> There is a benefit when you teach Pharo and write a book.
>> >>
>> >> Then you should make the Exception hierarchy a subclass of Event too
>> >> and rename all exceptions, because they are all (exceptional) events
>> >> too.
>> >>
>> >>>> i completely agree that proper naming is important. but the framework
>> >>>> was originally designed not by us,
>> >>>> and i think its not quite correct to rename it without asking the
>> >>>> author.
>> >>>
>> >>> This is what this email is about :-)
>> >>
>> >> Puns aside: Why not just remove the Announcement class altogether? It
>> >> used to be empty in the original implementation and serves no real
>> >> purpose other than grouping its subclasses. Any object can potentially
>> >> represent an event.
>> >>
>> > err.. an Announcement playing own role as a root class for all
>> > announcements.
>> > In same way as Exception is a root of all exceptions, so if you want
>> > to handle all exceptions you putting Exception class.
>> > If you remove the notion of root, then you will need to introduce
>> > something else in order to satisfy 'i wanna handle all
>> > exceptions/events ,
>> > no matter what they are'.
>>
>> Object would be your choice for all events then.
>>
>> Lukas
>>
>> --
>> Lukas Renggli
>> www.lukas-renggli.ch
>>
>
>
>
> --
> Hern�n Wilkinson
> Agile Software Development, Teaching & Coaching
> Mobile: +54 - 911 - 4470 - 7207
> email: hernan.wilkinson@10Pines.com
> site:�http://www.10Pines.com
> Address: Paraguay�523, Floor 7 N, Buenos Aires, Argentina
>

--
Best regards,
Igor Stasenko.