On Sat, Oct 8, 2011 at 2:35 AM, Hernan Wilkinson < [email protected]> wrote:
> > > 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" > You're reviving the entire discussion over ANSI exceptions, the Digitalk one based on classes and the instance-based on from ParcPlace. The conclusion is that the class-based system is better on balance. Classes are cheap, their names are really useful when well-chosen and being able to add behaviour to specific exceptions is a huge win. As has been pointed out, creating exception sets with #, means classes of exception can be conveniently combined. So at least for me it is better to let sleeping dogs lie and continue to enjoy class-based exceptions (and class0-based announcements). But I think the bottom line is that the declarative nature of classes is extremely useful in making a system comprehensible and navigable by the programmer. Look at how prototype-based languages end up inventing things close to classes for precisely these reasons. 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 > > -- best, Eliot
