Hi Eliot! On Sat, Oct 8, 2011 at 3:00 PM, Eliot Miranda <[email protected]>wrote:
> > > You're reviving the entire discussion over ANSI exceptions, the Digitalk > one based on classes and the instance-based on from ParcPlace. > Not exactly... I was only suggesting that is not good to couple class hierarchy with exception handling... > The conclusion is that the class-based system is better on balance. > I agree with that... I have used the VA exception based on ExceptionalEvent and Signal and as you say, I prefer to have classes to model exceptions Classes are cheap, their names are really useful when well-chosen and being > able to add behaviour to specific exceptions is a huge win. > Yes, agree > 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). > I agree, again, I was trying to say that selecting a exception handler should not be only close to a class and its subclasses, and I showed in a previous example how that is supported currently in Pharo, which I think it is great. Well, I hope I made myself clear :-) Bye! Hernan. > 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 > > -- *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
