Notification extends Exception...
Hi, For Moose on web, I have to implement the loading of a Moose Model by a HTML post request. This request send a file which have to been parsed to create a model. The parsing launch a Job (by an UIManager) and the Job throws a JobStartNotification at his beginning. JobStartNotification is a subclass of Exception. I use a Zinc Server. So when I do the request, Zinc catch the Exception and send an error as response. Has a Notification to be considered like an Exception and not like a catchable object, because it's just some information... ? Cheers, Vincent
On 11 July 2013 14:06, Vincent Blondeau <vincent.blondeau@polytech-lille.net> wrote:
Hi,
For Moose on web, I have to implement the loading of a Moose Model by a HTML post request. This request send a file which have to been parsed to create a model.
The parsing launch a Job (by an UIManager) and the Job throws a JobStartNotification at his beginning. JobStartNotification is a subclass of Exception. I use a Zinc Server. So when I do the request, Zinc catch the Exception and send an error as response.
Has a Notification to be considered like an Exception and not like a catchable object, because it's just some information... ?
Exceptions are exactly the catchable objects. A Notification is typically used to signal some event to a piece of code lower down the call stack. Subclasses of Error represent what other languages call exceptions. frank
Cheers, Vincent
On 11 July 2013 15:06, Vincent Blondeau <vincent.blondeau@polytech-lille.net> wrote:
Hi,
For Moose on web, I have to implement the loading of a Moose Model by a HTML post request. This request send a file which have to been parsed to create a model.
The parsing launch a Job (by an UIManager) and the Job throws a JobStartNotification at his beginning. JobStartNotification is a subclass of Exception. I use a Zinc Server. So when I do the request, Zinc catch the Exception and send an error as response.
Has a Notification to be considered like an Exception and not like a catchable object, because it's just some information... ?
It is not a question that Notification should be an Exception, but question, if zinc should treat all exceptions as errors.
Cheers, Vincent
-- Best regards, Igor Stasenko.
An exception sounds to me like something that is not expected. In my opinion, a notification is not an exception but just an information. Esteban told me that this discussion has already occurs but I was not able to find it. 2013/7/11 Igor Stasenko <siguctua@gmail.com>
On 11 July 2013 15:06, Vincent Blondeau <vincent.blondeau@polytech-lille.net> wrote:
Hi,
For Moose on web, I have to implement the loading of a Moose Model by a HTML post request. This request send a file which have to been parsed to create a model.
The parsing launch a Job (by an UIManager) and the Job throws a JobStartNotification at his beginning. JobStartNotification is a subclass of Exception. I use a Zinc Server. So when I do the request, Zinc catch the Exception and send an error as response.
Has a Notification to be considered like an Exception and not like a catchable object, because it's just some information... ?
It is not a question that Notification should be an Exception, but question, if zinc should treat all exceptions as errors.
Cheers, Vincent
-- Best regards, Igor Stasenko.
-- *Guillaume Larcheveque*
On 11 July 2013 14:26, Guillaume Larcheveque <guillaume.larcheveque@gmail.com> wrote:
An exception sounds to me like something that is not expected. In my opinion, a notification is not an exception but just an information.
It's a terminology problem. The Smalltalk class Exception does not represent the same thing as the Ruby or Java Exception classes. Smalltalk's Error class is what everyone else calls an exception. A Smalltak Exception is just a thing that can communicate with some other bit of code - a handler - somewhere down the call stack. If you have any familiarity with Common Lisp, you can think of Smalltalk's Exception as a condition [1]. [1] http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-res... frank
Esteban told me that this discussion has already occurs but I was not able to find it.
2013/7/11 Igor Stasenko <siguctua@gmail.com>
On 11 July 2013 15:06, Vincent Blondeau <vincent.blondeau@polytech-lille.net> wrote:
Hi,
For Moose on web, I have to implement the loading of a Moose Model by a HTML post request. This request send a file which have to been parsed to create a model.
The parsing launch a Job (by an UIManager) and the Job throws a JobStartNotification at his beginning. JobStartNotification is a subclass of Exception. I use a Zinc Server. So when I do the request, Zinc catch the Exception and send an error as response.
Has a Notification to be considered like an Exception and not like a catchable object, because it's just some information... ?
It is not a question that Notification should be an Exception, but question, if zinc should treat all exceptions as errors.
Cheers, Vincent
-- Best regards, Igor Stasenko.
-- Guillaume Larcheveque
Vincent, On 11 Jul 2013, at 15:06, Vincent Blondeau <vincent.blondeau@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
Le 11/07/2013 15:42, Sven Van Caekenberghe a écrit :
Vincent,
On 11 Jul 2013, at 15:06, Vincent Blondeau <vincent.blondeau@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 ] ] Vicnent
On 11 Jul 2013, at 16:08, Vincent Blondeau <vincent.blondeau@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@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
Catching all/any Exception is generally considered a code smell 2013/7/11 Sven Van Caekenberghe <sven@stfx.eu>
On 11 Jul 2013, at 16:08, Vincent Blondeau < vincent.blondeau@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@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
On 11 Jul 2013, at 18:05, Nicolas Cellier <nicolas.cellier.aka.nice@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@stfx.eu>
On 11 Jul 2013, at 16:08, Vincent Blondeau <vincent.blondeau@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@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
On 2013-07-11, at 18:12, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 11 Jul 2013, at 18:05, Nicolas Cellier <nicolas.cellier.aka.nice@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...).
On 11 July 2013 17:26, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-07-11, at 18:12, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 11 Jul 2013, at 18:05, Nicolas Cellier <nicolas.cellier.aka.nice@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
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@gmail.com>
On 11 July 2013 17:26, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-07-11, at 18:12, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 11 Jul 2013, at 18:05, Nicolas Cellier < nicolas.cellier.aka.nice@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*
On 11 July 2013 19:20, Guillaume Larcheveque <guillaume.larcheveque@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@gmail.com>
On 11 July 2013 17:26, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-07-11, at 18:12, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 11 Jul 2013, at 18:05, Nicolas Cellier <nicolas.cellier.aka.nice@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
Am 11.07.2013 um 18:05 schrieb Nicolas Cellier <nicolas.cellier.aka.nice@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@stfx.eu>
On 11 Jul 2013, at 16:08, Vincent Blondeau <vincent.blondeau@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@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
participants (8)
-
Camillo Bruni -
Frank Shearar -
Guillaume Larcheveque -
Igor Stasenko -
Nicolas Cellier -
Norbert Hartl -
Sven Van Caekenberghe -
Vincent Blondeau