On Sat, Oct 8, 2011 at 6:06 AM, Lukas Renggli <[email protected]> wrote:
> 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. > yes... so let me put it in another way... hmm what I'm trying to say is that using THE class as the condition to handle an exception (i.e. as the parameter of the on: keyword) should not be the ONLY way to express "I want to handle this exceptional case". Doing so leads us to the necessity of creating unnecessary exceptions hierarchies where the only reason to have an exception subclass is to be able to handle that particular exceptional case, and in the 90% of the cases, those classes do not define any behavior... to name a few, the RegexError hierarchy or XMLParserException hierarchy or the Halt hierarchy, their subclasses do not define any particular behavior So we are telling the programmer "hey!, if you want to handle an exception, put the exception class here", therefore any problem related to handling exceptions will be solved based on the class and its hierarchy, we are narrowing the options the define witch exception to handle. On the other hand, if we say "hey! if you want to handle an exception, just write the condition that identifies that exception here", then we are making the options to handle exceptions "bigger" Anyway, I found this useful in two cases and it helps me to explain what exceptions are really and how to avoid those big/depth exceptions hierarchies very common in "inexperienced" programmers... and when I found I could do something like this it blowed my head :-) > 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 > > -- *Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: [email protected] site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina
