Yes, but likely you are using leave nodes in such expressions. I don't think that MouseMovedAnnouncement, MouseClickedAnnouncement, ZeroDivideException , IndexOutOfBoundsException , or IllegalStateException are abstract or would have any subclasses.
On 7 October 2011 23:54, Hernan Wilkinson <[email protected]> wrote: > yes yes, but using #, still has the coupling with the class hierarchy... I > mean, if you write: > [] on: Exc1, Exc2 do: [...] > It will handle Exc1 and it subclasses and Exc2 and its subclasses... I can > not handle just Exc1 and Exc2 > What I tried to say is that handling a class and its subclasses is an > special case of handling a collection of classes and if we can handle any > group of classes, then handling a hierarchy is just trivial, a particular > case of handling a group, then handling the hierarchy creates > an unnecessary coupling, maybe handy but not necessary, and showing > programmers that is not a RULE for the exception handling mechanism to > always handle a hierarchy just "break their head"... (I don't remember the > phrase for that in English :-) ) > > On Fri, Oct 7, 2011 at 3:42 PM, Lukas Renggli <[email protected]> wrote: >> >> Actually both -- Announcement and Exception -- implement #, to create >> such a collection: >> >> anAnnouncer >> on: MouseMovedAnnouncement , MouseClickedAnnouncement >> do: [ :ann | ... ] >> >> [ ... ] >> on: ZeroDivideException , IndexOutOfBoundsException , >> IllegalStateException >> do: [ :err | ... ] >> >> Lukas >> >> On 7 October 2011 20:30, Hernan Wilkinson <[email protected]> >> wrote: >> > >> > >> > On Fri, Oct 7, 2011 at 12:41 PM, Igor Stasenko <[email protected]> >> > wrote: >> >> >> >> On 7 October 2011 13:53, Hernan Wilkinson >> >> <[email protected]> >> >> 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 <[email protected]> >> >> > wrote: >> >> >> >> >> >> On 6 October 2011 17:40, Igor Stasenko <[email protected]> wrote: >> >> >> > On 6 October 2011 17:24, Lukas Renggli <[email protected]> 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: [email protected] >> >> > site: http://www.10Pines.com >> >> > Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina >> >> > >> >> >> >> >> >> >> >> -- >> >> Best regards, >> >> Igor Stasenko. >> >> >> > >> > >> > >> > -- >> > Hernán Wilkinson >> > Agile Software Development, Teaching & Coaching >> > Mobile: +54 - 911 - 4470 - 7207 >> > email: [email protected] >> > site: http://www.10Pines.com >> > Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina >> > >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > > > -- > Hernán Wilkinson > Agile Software Development, Teaching & Coaching > Mobile: +54 - 911 - 4470 - 7207 > email: [email protected] > site: http://www.10Pines.com > Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina > -- Lukas Renggli www.lukas-renggli.ch
