October 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] better error handling

by Alexandre Bergel

> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 1, 2009

Re: [Pharo-project] better error handling

by Igor Stasenko

2009/10/1 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > 2009/10/1 Hernan Wilkinson <hernan.wilkinson(a)gmail.com> >> >> 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' ] >> > 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 ] 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.

Oct. 1, 2009

Re: [Pharo-project] test pragmas

by Lukas Renggli

2009/10/1 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > I was thinking that we discuss with james foster and niall about a > versions for all the smalltalk in Suni3.3 > Do you recall it lukas? Yeah, we listed the important features. Expected failures was one. Being able to categorize tests was another one, but I don't remember the other ones right now. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 1, 2009

Re: [Pharo-project] better error handling

by Benjamin Pollack

2009/10/1 Mariano Martinez Peck <marianopeck(a)gmail.com> > 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... > 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

Oct. 1, 2009

Re: [Pharo-project] StrikeFont Accujen in Pharo

by Henrik Sperre Johansen

On 01.10.2009 15:33, Jochen wrote: > Damien Cassou schrieb: >> 2009/9/30 Jochen<ich(a)nichtich.com>: >> >>> So my question is, if it's possible to get the Accujen into Pharo. The >>> StrikeFont class still exists but it seams like all fonts but DejaVu are >>> missing now. >>> >> >> What happens when you browse the list of available fonts (World >> menu->System->Preferences->System fonts->default text fonts) ? >> >> > In this list the available fonts are all TrueType fonts in my System > (Windows) and the fonts in the "Fonts" subdirectory of Pharo (that are > all versions of DejaVU*.ttf). Also there's the font "Accuny" that is > afaik a StrikeFont. But unfortunatly no "Accujen". All bitmapped fonts except Accuny were removed about a year ago to save space, as far as I can remember. The last Pharo-image containing Accujen seems to be 10107, it's available from the archives. You could try to extract it as a package from either there or a recent Squeak image, where I think it's still included. Alternatively, evaluate StrikeFont installDejaVu (warning: will change the default fonts), and see if Bitmap DejaVu Sans size 7 is adequate for your needs. (Either way, it shows off how to install a font in the system) Cheers, Henry

Oct. 1, 2009

Re: [Pharo-project] test pragmas

by StÃ©phane Ducasse

I was thinking that we discuss with james foster and niall about a versions for all the smalltalk in Suni3.3 Do you recall it lukas? On Oct 1, 2009, at 10:07 PM, Lukas Renggli wrote: > #expectedFailures could be implemented like this and we could support > strategies: > > TestCase class>>expectedFailures > ^ (Pragma allNamed: #expectedFailure from: self to: TestCase) > collect: [ :each | each selector ] > > Lukas > > 2009/10/1 Adrian Lienhard <adi(a)netstyle.ch>: >> Actually it would make sense to use pragmas as the information gets >> closer to the test. Any taker? >> >> Adrian >> >> On Sep 22, 2009, at 13:24 , Damien Cassou wrote: >> >>> On Tue, Sep 22, 2009 at 12:24 PM, Tudor Girba <girba(a)iam.unibe.ch> >>> wrote: >>>> How can I mark a test as being an expected failure? >>> >>> you do not need a pragma. Instead, override #expectedFailures and >>> return an array of selectors. >>> >>> -- >>> Damien Cassou >>> http://damiencassou.seasidehosting.st >>> >>> "Lambdas are relegated to relative obscurity until Java makes them >>> popular by not having them." James Iry >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 1, 2009

Re: [Pharo-project] test pragmas

by Lukas Renggli

#expectedFailures could be implemented like this and we could support strategies: TestCase class>>expectedFailures ^ (Pragma allNamed: #expectedFailure from: self to: TestCase) collect: [ :each | each selector ] Lukas 2009/10/1 Adrian Lienhard <adi(a)netstyle.ch>: > Actually it would make sense to use pragmas as the information gets > closer to the test. Any taker? > > Adrian > > On Sep 22, 2009, at 13:24 , Damien Cassou wrote: > >> On Tue, Sep 22, 2009 at 12:24 PM, Tudor Girba <girba(a)iam.unibe.ch> >> wrote: >>> How can I mark a test as being an expected failure? >> >> you do not need a pragma. Instead, override #expectedFailures and >> return an array of selectors. >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Lambdas are relegated to relative obscurity until Java makes them >> popular by not having them." James Iry >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 1, 2009

Re: [Pharo-project] test pragmas

by Adrian Lienhard

Actually it would make sense to use pragmas as the information gets closer to the test. Any taker? Adrian On Sep 22, 2009, at 13:24 , Damien Cassou wrote: > On Tue, Sep 22, 2009 at 12:24 PM, Tudor Girba <girba(a)iam.unibe.ch> > wrote: >> How can I mark a test as being an expected failure? > > you do not need a pragma. Instead, override #expectedFailures and > return an array of selectors. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 1, 2009

Re: [Pharo-project] better error handling

by Mariano Martinez Peck

On Thu, Oct 1, 2009 at 3:54 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > 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. > excellent > > > 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. > Ok, I will do that then. > I could send the exception chapter too :) > please do!!! > > > > > 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 > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 1, 2009

Re: [Pharo-project] better error handling

by Mariano Martinez Peck

2009/10/1 Hernan Wilkinson <hernan.wilkinson(a)gmail.com> > 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' ] > > 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... > > 2009/10/1 Mariano Martinez Peck <marianopeck(a)gmail.com> > >> 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 >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 1, 2009