For me there are much more important things to fix or make better :) Stef
> I haven't read the chapter yet, but there is something that bothers me a > little about the Exception hierarchy... what I've seen lately is that > Exceptions are not used only as exceptions but as a why to get context > information (for example Seaside with WACurrentRequestContext), notify about > an event (for example the Notification class and subclasses), etc. > Despite if it is a good idea to solve this issues with exceptions, calling > Exception to the root of the hierarchy makes a lot of noise (at least to > me... I mean, a Notification is not an Exception, something you were not > expecting... getting the current context has nothing to do with an > exception...)... So, have you think about changing the name to that class and > making the protocol simpler (at least for the root of the hierarchy) so all > these types of uses fit better than they do today? (for example, retrying a > notification looks like no sense, the same for wacurrentrequestcontext) > I think that the idea of "crawling" on the execution stack or the execution > flow have more sense as metaphor to look for another name... > Anyway, just a thought. > Bye, > Hernan. > > 2010/3/3 Stéphane Ducasse <[email protected]> > Thanks laurent > > Stef > > > Begin forwarded message: > >> From: laurent laffont <[email protected]> >> Date: March 3, 2010 10:09:32 PM GMT+01:00 >> To: Stéphane Ducasse <[email protected]> >> Subject: Re: [Pharo-project] Pharo by Example vol 2: new chapter available >> >> Some notes: >> >> Page 1: The basic idea behing exception .... I would expect a schema to show >> the workflow. >> >> Page 8: When an exception is signaled, the exception handling mechanism >> ....I've read it 3 times (for something finally quite simple), maybe it >> needs a sequence diagram or reformulation. >> >> Section 1.15: How exceptions are implemented. I had to read several times to >> understand, lot of informations to handle at once. >> >> Page 27 (bottom): For example, in method 1.1 ... specify "on page 19" or put >> the snippet again so we can easily compare with method 1.2. >> >> I like the "real code" examples. The "How..." sections too. >> >> When not to use Exceptions: not to "hide errors". I have too many times >> seen try ... catch ... to hide errors to the users. >> >> Maybe add a "When to use Exceptions" section, reminding the "Crash early" >> principle. >> >> Laurent Laffont >> >> >> On Tue, Mar 2, 2010 at 2:26 PM, Stéphane Ducasse <[email protected]> >> wrote: >> Hi guys >> >> We just released a new chapter for Pharo by Example Vol.2 on Exceptions >> http://pharobyexample.org/ >> >> Let us know what you think. >> >> Stef >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
