Fwd: Pharo by Example vol 2: new chapter available

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: Pharo by Example vol 2: new chapter available

Stéphane Ducasse
Thanks laurent

Stef


Begin forwarded message:

From: laurent laffont <[hidden email]>
Date: March 3, 2010 10:09:32 PM GMT+01:00
To: Stéphane Ducasse <[hidden email]>
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 <[hidden email]> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Pharo by Example vol 2: new chapter available

hernan.wilkinson
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 <[hidden email]>
Thanks laurent

Stef


Begin forwarded message:

From: laurent laffont <[hidden email]>
Date: March 3, 2010 10:09:32 PM GMT+01:00
To: Stéphane Ducasse <[hidden email]>
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 <[hidden email]> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Pharo by Example vol 2: new chapter available

Alexandre Bergel
hi Hernan,

You're very right saying that exception are often abused. In Java, you  
have a class Throwable.

Cheers,
Alexandre


On 9 Mar 2010, at 08:10, Hernan Wilkinson wrote:

> 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 <[hidden email]>
> Thanks laurent
>
> Stef
>
>
> Begin forwarded message:
>
>> From: laurent laffont <[hidden email]>
>> Date: March 3, 2010 10:09:32 PM GMT+01:00
>> To: Stéphane Ducasse <[hidden email]>
>> 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 <[hidden email]
>> > 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Pharo by Example vol 2: new chapter available

hernan.wilkinson
hey, you are right, I forgot about that in Java.

On Tue, Mar 9, 2010 at 8:31 AM, Alexandre Bergel <[hidden email]> wrote:
hi Hernan,

You're very right saying that exception are often abused. In Java, you have a class Throwable.

Cheers,
Alexandre



On 9 Mar 2010, at 08:10, Hernan Wilkinson wrote:

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 <[hidden email]>
Thanks laurent

Stef


Begin forwarded message:

From: laurent laffont <[hidden email]>
Date: March 3, 2010 10:09:32 PM GMT+01:00
To: Stéphane Ducasse <[hidden email]>
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 <[hidden email]> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






_______________________________________________


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Pharo by Example vol 2: new chapter available

Stéphane Ducasse
In reply to this post by hernan.wilkinson
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 <[hidden email]>
> Thanks laurent
>
> Stef
>
>
> Begin forwarded message:
>
>> From: laurent laffont <[hidden email]>
>> Date: March 3, 2010 10:09:32 PM GMT+01:00
>> To: Stéphane Ducasse <[hidden email]>
>> 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 <[hidden email]> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Pharo by Example vol 2: new chapter available

Mariano Martinez Peck
In reply to this post by hernan.wilkinson


2010/3/9 Hernan Wilkinson <[hidden email]>
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.

+1.

 
Bye,
Hernan.

2010/3/3 Stéphane Ducasse <[hidden email]>

Thanks laurent

Stef


Begin forwarded message:

From: laurent laffont <[hidden email]>
Date: March 3, 2010 10:09:32 PM GMT+01:00
To: Stéphane Ducasse <[hidden email]>
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 <[hidden email]> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project