Hi Eliot! On Sat, Oct 8, 2011 at 3:00 PM, Eliot Miranda <eliot.miranda@gmail.com>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 <hernan.wilkinson@10pines.com> 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 <renggli@gmail.com> 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 <
hernan.wilkinson@10pines.com>
wrote:
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.
-- 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
-- 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
-- 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 <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: hernan.wilkinson@10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina