On 12/20/2010 09:27 PM, Hernán Morales Durand wrote:
2010/12/20 Esteban Lorenzano<[email protected]>:
duh...
[ ... ] on: Warning do: [ :w | w resume ].
forget my question... :(
That wouldn't make it for Notifications such as:
self inform: 'test'
so you might want to write:
[ self inform: 'test' ]
on: Warning, Notification
do: [: ex | ex return: 'Ignored: ' , ex class name , ' ' , ex messageText ].
I would be careful about handling all Notifications. Unlike Error, there
is no "correct" pattern for handling Notifications, just take a look at
all implementors of #defaultAction for subclasses of Notification and
you will see that in most cases, the default action returns an
application specific object, so returning a String instead will break
them all ..
Notifications are meant to be ignored unless you know what you are doing.
It turns out that even handling Warning can be dangerous. For Warning it
is correct to use #resume to ignore the Warning (which ends up doing a
`ex resume: nil`). However, UndeclaredVariableWarning (a subclass of
Warning) expects a Boolean result, so if the code you are wrapping does
any compiles you'll have to special case UndeclaredVariableWarning to do
`ex resume: true`.
To ignore #inform: in Pharo, handling ProvideAnswerNotification is a
better choice than Notification, but you need to be aware of the
implications of ignoring inform: as ProvideAnswerNotification is used
for dealing with:
inform: - return value is ignored
confirm:: - return values is expected to be a Boolean
request: - is expected to be a String
As Adrian mentions, if you are want to automate the handling of
inform:/confirm:/request: you are better off using valueSupplyingAnswers:.
Finally, in the above example using 'ex return:'a string` is not the
correct way to ignore a Warning or Notification. The #return: messages
returns the arg as the result of the block (unwinding the stack).
#resume: returns the arg as the result of the #signal: and continues
execution from that point. Take a look at the different results for the
following two expressions:
| w x y z |
w := x:= y:= z:= nil.
x:= [ w := #before.
y:= self confirm: 'test'.
z := #after ]
on: ProvideAnswerNotification
do: [:ex | ex return: false ].
{w. x. y. z.}.
| w x y z |
w := x:= y:= z:= nil.
x:= [ w := #before.
y:= self confirm: 'test'.
z := #after ]
on: ProvideAnswerNotification
do: [:ex | ex resume: false ].
{w. x. y. z.}.
Hernán this is common mistake when putting together simple examples and
if I hadn't just finished writing a series of automatic Warning
handlers, I wouldn't have picked up on it:)
Dale
