>> 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?
it would be nice to have one.
Hernan could you open a ticket? and if you provide code it will get in :)
>
>> 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.
>
