Hi folks: First of all I have to say I am pretty sad that error handling hasn't a special place in the PBE. In my opinion having a good error handling is a MUST in every piece of code. We need to use exceptions. I didn't collaborate at all with PBE so I cannot say anything to no one :) I will try to write something for the next version if you want. But first...
We need a better error handling. It is very common to have a hierarchy of exceptions or errors. You have subclasses of Error for example. And many times, you want to do or not to do or even do something different depending on the error you got. Now, the question is, how you do this in Squeak ??? This is the only (ugly) way I find to do it: [ a block of code where you do something that can singal different exceptions ] on: XXXErrror do: [ : ex | ex class = XXXError if True: [ 'I do what I need to do when I get the error XXX' ]. ex class = YYYError if True: [ 'I do what I need to do when I get the error YYY' ]. 'here I do in the rest of the cases' ] But, I would like to have something like this: [ a block of code where you do something that can singal different exceptions ] on: XXXError do: [ : ex | 'I do what I need to do when I get the error XXX' ] on: YYYError do: [ : ex | 'I do what I need to do when I get the error YYY' ] on: Error do: [ : ex | 'here I do in the rest of the cases' ] ensure: [ 'Here I do what I always need to do, no matter if there is an error or not' ] What do you think about this? does someone ever did something like this ? perhaps we can put this as part of 1.1 I listen opinions. Best, Mariano _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
do this...
[[[[ a block of code where you do something that can singal different exceptions ] on: XXXError do: [ : ex | 'I do what I need to do when I get the error XXX' ]] on: YYYError do: [ : ex | 'I do what I need to do when I get the error YYY' ]] on: Error do: [ : ex | 'here I do in the rest of the cases' ]] ensure: [ 'Here I do what I always need to do, no matter if there is an error or not' ]
2009/10/1 Mariano Martinez Peck <[hidden email]> Hi folks: First of all I have to say I am pretty sad that error handling hasn't a special place in the PBE. In my opinion having a good error handling is a MUST in every piece of code. We need to use exceptions. I didn't collaborate at all with PBE so I cannot say anything to no one :) I will try to write something for the next version if you want. But first... _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Mariano Martinez Peck
On Oct 1, 2009, at 8:02 PM, Mariano Martinez Peck wrote: > Hi folks: First of all I have to say I am pretty sad that error > handling hasn't a special place in the PBE. In my opinion having a > good error handling is a MUST in every piece of code. We need to use > exceptions. I didn't collaborate at all with PBE so I cannot say > anything to no one :) I will try to write something for the next > version if you want. But first... there is a chapter for the volume two. It is already written and was rewritten we will release it in the future for making the unpatient happy. > We need a better error handling. It is very common to have a > hierarchy of exceptions or errors. You have subclasses of Error for > example. And many times, you want to do or not to do or even do > something different depending on the error you got. Now, the > question is, how you do this in Squeak ??? have a look at the Exceptions test because they encode the rich exception mechanism of Smalltalk. I could send the exception chapter too :) > > This is the only (ugly) way I find to do it: > > [ a block of code where you do something that can singal different > exceptions ] > on: XXXErrror do: [ : ex | ex class = XXXError if True: [ 'I > do what I need to do when I get the error XXX' ]. > ex class = YYYError if > True: [ 'I do what I need to do when I get the error YYY' ]. > 'here I do in the rest of > the cases' > ] > > > But, I would like to have something like this: > > > [ a block of code where you do something that can singal different > exceptions ] > on: XXXError > do: [ : ex | 'I do what I need to do when I get the error > XXX' ] > on: YYYError > do: [ : ex | 'I do what I need to do when I get the error > YYY' ] > on: Error > do: [ : ex | 'here I do in the rest of the cases' ] > ensure: [ 'Here I do what I always need to do, no matter if > there is an error or not' ] > > > What do you think about this? does someone ever did something like > this ? perhaps we can put this as part of 1.1 > > I listen opinions. > > Best, > > Mariano > _______________________________________________ > 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 |
In reply to this post by hernan.wilkinson
2009/10/1 Hernan Wilkinson <[hidden email]> do this... Thanks Hernán, it is quite better!!! However, I still would love not to use all the brackets ;) I would use this way for the moment...
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Stéphane Ducasse
On Thu, Oct 1, 2009 at 3:54 PM, Stéphane Ducasse <[hidden email]> wrote:
excellent
Ok, I will do that then. I could send the exception chapter too :) please do!!!
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Mariano Martinez Peck
2009/10/1 Mariano Martinez Peck <[hidden email]>
As a compromise, you could do what Array does with its with:with:with:with: style thing and make BlockClosure>>on:do:on:do:on:do:, nesting the blocks yourself. Alternatively, it'd be quite easy to add BlockClosure>>onAllDo:, which took a Dictionary mapping exception classes to blocks and called the appropriate one based on the actual exception raised. With the recent closure changes, your blocks will actually work as expected, too, rather than trampling random method variables on execution. :)
--Benjamin _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Mariano Martinez Peck
2009/10/1 Mariano Martinez Peck <[hidden email]>:
> > > 2009/10/1 Hernan Wilkinson <[hidden email]> >> >> do this... >> >> [[[[ a block of code where you do something that can singal different >> exceptions ] >> on: XXXError >> do: [ : ex | 'I do what I need to do when I get the error XXX' ]] >> on: YYYError >> do: [ : ex | 'I do what I need to do when I get the error YYY' ]] >> on: Error >> do: [ : ex | 'here I do in the rest of the cases' ]] >> ensure: [ 'Here I do what I always need to do, no matter if there is >> an error or not' ] >> > [ a block of code where you do something that can singal different exceptions ] on: Error do: [:ex | ex visitWith: self ] and then in each error subclass, you can do visitWith: handler ^ handler handleXXXerror: self while, by default, Error could implement this method as: visitWith: handler ^ handler handleError: self so, instead of bunch of cases, you having a bunch of methods, which handling particular case. -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Mariano Martinez Peck
> there is a chapter for the volume two. It is already written and was
> rewritten we will release it in the future for making the unpatient > happy. > > excellent We put a lot of work in this chapter. Getting the semantic and explanation right was not trivial. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Igor Stasenko
Igor,
I'm trying to understand your suggestion. Am I thinking correclty? Thanks in advance! On Thu, Oct 1, 2009 at 23:42, Igor Stasenko <[hidden email]> wrote: How about a visitor pattern? I had to replace self with a class handling the errors: [ZeroDivide new signal: 'zero']
on: Error do: [:error | error visitWith: (MyErrorHandler new)].
Error>>visitWith: anErrorHandler ^ anErrorHandler handleError: self MyErrorHandler>>handleError: anError
^anError signal Error subclass: #AlexError AlexError>>visitWith: anErrorHandler ^ anErrorHandler handleAlexError: self
AlexError>>handleAlexError: anAlexError ^'Handling an AlexError now.' _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
2009/10/2 Alex Schenkman <[hidden email]>:
> Igor, > I'm trying to understand your suggestion. > Am I thinking correclty? > Thanks in advance! > On Thu, Oct 1, 2009 at 23:42, Igor Stasenko <[hidden email]> wrote: >> >> How about a visitor pattern? >> >> [ a block of code where you do something that can singal different >> exceptions ] >> on: Error do: [:ex | >> ex visitWith: self >> ] >> > I had to replace self with a class handling the errors: > [ZeroDivide new signal: 'zero'] > on: Error do: > [:error | error visitWith: (MyErrorHandler new)]. > > Error>>visitWith: anErrorHandler > ^ anErrorHandler handleError: self > > MyErrorHandler>>handleError: anError > ^anError signal > > > Error subclass: #AlexError > AlexError>>visitWith: anErrorHandler > ^ anErrorHandler handleAlexError: self > AlexError>>handleAlexError: anAlexError > ^'Handling an AlexError now.' > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |