July 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Notification extends Exception...

by Camillo Bruni

On 2013-07-11, at 18:12, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > On 11 Jul 2013, at 18:05, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> Catching all/any Exception is generally considered a code smell > > In Pharo 3.0 AssertionFailure inherits from Error, which takes away my reason to catch Exception instead of Error. I always think we should add something like AbstractException which only contains the minimal interface. For me Exception has the wrong name (of course my bad Java experience doesn't help here...).

July 11, 2013

Re: [Pharo-dev] Notification extends Exception...

by Norbert Hartl

Am 11.07.2013 um 18:05 schrieb Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > Catching all/any Exception is generally considered a code smell > Not if you reach the borders of a defined system. In the smalltalk system this is an unhandled exception: it catches it and opens a debugger on it. In Svens case it is similar because the border from smalltalk to network forces him to handle all exceptions or better translate them into another error which is an HTTP error 5xx. Norbert > > 2013/7/11 Sven Van Caekenberghe <sven(a)stfx.eu> > > On 11 Jul 2013, at 16:08, Vincent Blondeau <vincent.blondeau(a)polytech-lille.net> wrote: > > > Le 11/07/2013 15:42, Sven Van Caekenberghe a Ã©crit : > >> Vincent, > >> > >> On 11 Jul 2013, at 15:06, Vincent Blondeau <vincent.blondeau(a)polytech-lille.net> wrote: > >> > >>> I use a Zinc Server. So when I do the request, Zinc catch the Exception and send an error as response. > >> ZnSingleThreadedServer>>#handleRequestProtected: request > >> "Handle request and return a response. > >> If a Smalltalk Error is thrown, return a HTTP Server Error response." > >> > >> ^ [ self authenticateAndDelegateRequest: request ] > >> on: Error > >> do: [ :exception | > >> self debugMode > >> ifTrue: [ exception pass ] > >> ifFalse: [ > >> self logServerError: exception. > >> ZnResponse serverError: exception printString ] ] > >> > >> AFAICT this code catches Error, not Exception, hence it would let Notification through. No ? > >> > >> Sven > >> > >> > > Indeed but I use the Zinc-Rest-Server and all Exceptions are caught: > > > > ZnRestServerDelegate>>handleRequest: request > > | call | > > (call := self match: request) > > ifNil: [ ^ self noHandlerFound: request ]. > > (self authenticate: call) > > ifFalse: [ ^ self callUnauthorized: request ]. > > ^ [ self execute: call ] > > on: Exception > > do: [ :exception | > > request server debugMode > > ifTrue: [ exception pass ] > > ifFalse: [ > > request server logServerError: exception. > > self serverError: request exception: exception ] ] > > > > Indeed. > > I know why I wrote that (I often write assertions in code, and AssertionFailed is not an Error, hence the broader net) - I will think about it. > > In the mean time, you could subclass ZnRestServerDelegate and override #handleRequest: > > Maybe I can also improve the overriding options a bit, like with an introduction of an #exceptionsToCatch accessor. > > HTH, > > Sven > > > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > > > > >

July 11, 2013

Re: [Pharo-dev] Notification extends Exception...

by Sven Van Caekenberghe

On 11 Jul 2013, at 18:05, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Catching all/any Exception is generally considered a code smell In Pharo 3.0 AssertionFailure inherits from Error, which takes away my reason to catch Exception instead of Error. > 2013/7/11 Sven Van Caekenberghe <sven(a)stfx.eu> > > On 11 Jul 2013, at 16:08, Vincent Blondeau <vincent.blondeau(a)polytech-lille.net> wrote: > > > Le 11/07/2013 15:42, Sven Van Caekenberghe a Ã©crit : > >> Vincent, > >> > >> On 11 Jul 2013, at 15:06, Vincent Blondeau <vincent.blondeau(a)polytech-lille.net> wrote: > >> > >>> I use a Zinc Server. So when I do the request, Zinc catch the Exception and send an error as response. > >> ZnSingleThreadedServer>>#handleRequestProtected: request > >> "Handle request and return a response. > >> If a Smalltalk Error is thrown, return a HTTP Server Error response." > >> > >> ^ [ self authenticateAndDelegateRequest: request ] > >> on: Error > >> do: [ :exception | > >> self debugMode > >> ifTrue: [ exception pass ] > >> ifFalse: [ > >> self logServerError: exception. > >> ZnResponse serverError: exception printString ] ] > >> > >> AFAICT this code catches Error, not Exception, hence it would let Notification through. No ? > >> > >> Sven > >> > >> > > Indeed but I use the Zinc-Rest-Server and all Exceptions are caught: > > > > ZnRestServerDelegate>>handleRequest: request > > | call | > > (call := self match: request) > > ifNil: [ ^ self noHandlerFound: request ]. > > (self authenticate: call) > > ifFalse: [ ^ self callUnauthorized: request ]. > > ^ [ self execute: call ] > > on: Exception > > do: [ :exception | > > request server debugMode > > ifTrue: [ exception pass ] > > ifFalse: [ > > request server logServerError: exception. > > self serverError: request exception: exception ] ] > > > > Indeed. > > I know why I wrote that (I often write assertions in code, and AssertionFailed is not an Error, hence the broader net) - I will think about it. > > In the mean time, you could subclass ZnRestServerDelegate and override #handleRequest: > > Maybe I can also improve the overriding options a bit, like with an introduction of an #exceptionsToCatch accessor. > > HTH, > > Sven > > > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > > > > >

July 11, 2013

Re: [Pharo-dev] Notification extends Exception...

by Nicolas Cellier

Catching all/any Exception is generally considered a code smell 2013/7/11 Sven Van Caekenberghe <sven(a)stfx.eu> > > On 11 Jul 2013, at 16:08, Vincent Blondeau < > vincent.blondeau(a)polytech-lille.net> wrote: > > > Le 11/07/2013 15:42, Sven Van Caekenberghe a Ã©crit : > >> Vincent, > >> > >> On 11 Jul 2013, at 15:06, Vincent Blondeau < > vincent.blondeau(a)polytech-lille.net> wrote: > >> > >>> I use a Zinc Server. So when I do the request, Zinc catch the > Exception and send an error as response. > >> ZnSingleThreadedServer>>#handleRequestProtected: request > >> "Handle request and return a response. > >> If a Smalltalk Error is thrown, return a HTTP Server Error > response." > >> > >> ^ [ self authenticateAndDelegateRequest: request ] > >> on: Error > >> do: [ :exception | > >> self debugMode > >> ifTrue: [ exception pass ] > >> ifFalse: [ > >> self logServerError: exception. > >> ZnResponse serverError: exception > printString ] ] > >> > >> AFAICT this code catches Error, not Exception, hence it would let > Notification through. No ? > >> > >> Sven > >> > >> > > Indeed but I use the Zinc-Rest-Server and all Exceptions are caught: > > > > ZnRestServerDelegate>>handleRequest: request > > | call | > > (call := self match: request) > > ifNil: [ ^ self noHandlerFound: request ]. > > (self authenticate: call) > > ifFalse: [ ^ self callUnauthorized: request ]. > > ^ [ self execute: call ] > > on: Exception > > do: [ :exception | > > request server debugMode > > ifTrue: [ exception pass ] > > ifFalse: [ > > request server logServerError: exception. > > self serverError: request exception: exception ] ] > > > > Indeed. > > I know why I wrote that (I often write assertions in code, and > AssertionFailed is not an Error, hence the broader net) - I will think > about it. > > In the mean time, you could subclass ZnRestServerDelegate and override > #handleRequest: > > Maybe I can also improve the overriding options a bit, like with an > introduction of an #exceptionsToCatch accessor. > > HTH, > > Sven > > > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > > > > >

July 11, 2013

[update 3.0] #30266

by Esteban Lorenzano

30266 ----- 11151 More changes needed to trait/classes polymorphism https://pharo.fogbugz.com/f/cases/11151/ (pass 3, one more to come)

July 11, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=win/… 1 regressions found. Tests.Release.ReleaseTest.testUnknownProcesses

July 11, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=mac/… 1 regressions found. Tests.Release.ReleaseTest.testUnknownProcesses

July 11, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/label=linu… 1 regressions found. Tests.CodeImport.ChunkImportTestCase.testImportAClassCategory

July 11, 2013

Re: [Pharo-dev] [Update 3.0] 30265

by Sebastian Tleye

Excellent!! 2013/7/11 Esteban Lorenzano <estebanlm(a)gmail.com> > 11151 More changes needed to trait/classes polymorphism > https://pharo.fogbugz.com/f/cases/11151/ > > (pass 2) > >

July 11, 2013

[Update 3.0] 30265

by Esteban Lorenzano

11151 More changes needed to trait/classes polymorphism https://pharo.fogbugz.com/f/cases/11151/ (pass 2)

July 11, 2013