a way to ignore warnings?

> cheers,
> Esteban
>
> Inicio del mensaje reenviado:
>
> De: Esteban Lorenzano <[hidden email]>
> Fecha: 20 de diciembre de 2010 21:22:49 GMT-03:00
> Para: Pharo Development <[hidden email]>
> Asunto: a way to ignore warnings?
>
> Hi,
> Is there a way to tell Pharo to ignore warning blocking messages? you those
> messages where you can press "proceed" and continue, for instance, loading a
> monticello package.
>
> cheers,
> Esteban
>

> 2010/12/20 Esteban Lorenzano <[hidden email]>:
>> 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 ].
>
> Cheers,
>
>> cheers,
>> Esteban
>>
>> Inicio del mensaje reenviado:
>>
>> De: Esteban Lorenzano <[hidden email]>
>> Fecha: 20 de diciembre de 2010 21:22:49 GMT-03:00
>> Para: Pharo Development <[hidden email]>
>> Asunto: a way to ignore warnings?
>>
>> Hi,
>> Is there a way to tell Pharo to ignore warning blocking messages? you those
>> messages where you can press "proceed" and continue, for instance, loading a
>> monticello package.
>>
>> cheers,
>> Esteban
>>
>
>
>
> --
> Hernán Morales
> Information Technology Manager,
> Institute of Veterinary Genetics.
> National Scientific and Technical Research Council (CONICET).
> La Plata (1900), Buenos Aires, Argentina.
> Telephone: +54 (0221) 421-1799.
> Internal: 422
> Fax: 425-7980 or 421-1799.
>

> 2010/12/20 Esteban Lorenzano<[hidden email]>:
>> 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 ].
>

> On 12/20/2010 09:27 PM, Hernán Morales Durand wrote:
>>
>> 2010/12/20 Esteban Lorenzano<[hidden email]>:
>>>
>>> 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.
>

> 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.}.
>

> Hi Dale,
>
> Thanks for your comments, some notes between lines...
>
> 2010/12/21 Dale Henrichs<[hidden email]>:
>> On 12/20/2010 09:27 PM, Hernán Morales Durand wrote:
>>>
>>> 2010/12/20 Esteban Lorenzano<[hidden email]>:
>>>>
>>>> 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,
>

>> 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,
>
> --
> Hernán Morales
> Information Technology Manager,
> Institute of Veterinary Genetics.
> National Scientific and Technical Research Council (CONICET).
> La Plata (1900), Buenos Aires, Argentina.
> Telephone: +54 (0221) 421-1799.
> Internal: 422
> Fax: 425-7980 or 421-1799.
>