- Pharo-dev - lists.pharo.org

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

by Frank Shearar

On 11 July 2013 19:20, Guillaume Larcheveque <guillaume.larcheveque(a)gmail.com> wrote: > In my opinion, Java have the right name: an exception is something that not > occurs every time by definition. In our case, a JobStartNotification is > always thrown; which is the opposite of an exception That's all fine and good, except Smalltalk defined what "exception" meant in 1980. Common Lisp uses the word "condition". Also, almost by definition, Java is wrong. frank > 2013/7/11 Frank Shearar <frank.shearar(a)gmail.com> >> >> On 11 July 2013 17:26, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> > 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...). >> >> Just think of it this way: Java got the name wrong! >> >> frank >> > > > > -- > Guillaume Larcheveque >

July 11, 2013

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

by Guillaume Larcheveque

In my opinion, Java have the right name: an exception is something that not occurs every time by definition. In our case, a JobStartNotification is always thrown; which is the opposite of an exception 2013/7/11 Frank Shearar <frank.shearar(a)gmail.com> > On 11 July 2013 17:26, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > 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...). > > Just think of it this way: Java got the name wrong! > > frank > > -- *Guillaume Larcheveque*

July 11, 2013

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

by Frank Shearar

On 11 July 2013 17:26, Camillo Bruni <camillobruni(a)gmail.com> wrote: > 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...). Just think of it this way: Java got the name wrong! frank

July 11, 2013

[update 3.0] #30267

by Esteban Lorenzano

July 11, 2013

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