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.