Hernán
I agree with you, because practicality outweighs correctness...
However I mainly wanted to point out that handling Notifications in the
general case is not a good idea ...
For development and personal scripts, where you can fix the problems on
the fly just about anything goes ...
Dale
On 12/21/2010 10:41 AM, Hernán Morales Durand wrote:
Hi Dale,
Thanks for your comments, some notes between lines...
2010/12/21 Dale Henrichs<[email protected]>:
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.
Agree. Although I think you're focusing on handling properly the
answer but Esteban just wanted to bypass modal dialogs so a time
consuming operation could finish without human intervention. In that
case we can assume he isn't going to provide a "dangerous" default for
a confirm operation and he'd like to log warnings and informations.
Esteban may you comment is that your case?
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`.
Yes, I've seen the UndeclaredVariableWarning (from
Encoder>>undeclared: ) dialog many times when compiling
programatically, and one of things is that I have to handle every
compilation to avoid this dialog like this:
[ self targetClass
compile: aString
classified: aCategoryClassification ]
on: UndeclaredVariableWarning
do: [: ex | self log: 'Warning UndeclaredVariableWarning in ' , self
targetClass asString , '>>' , aString asString ]
I didn't found a preference to ignore this dialog, although I've found
Parser warningAllowed -> false "That would be the More Warnings preference "
I wonder is there a setting I've missed?
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.}.
I don't know if assuming always that "correct" means continue
execution in that scope. It may depend on the warning or notification
and the block task, but of course #resume: is a more common sense
choice for most cases.
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:)
I know :) it could be as complex as hell, that's why I say you have to
automate exceptions with a specific goal in mind, for example logging
or finish an unattended loading.
Cheers,
