Status: Accepted Owner: hernan.m...@gmail.com Labels: Type-RequestForEnhancement Difficulty-Easy New issue 3518 by hernan.m...@gmail.com: #warningAllowed does not handle UndeclaredVariableWarning http://code.google.com/p/pharo/issues/detail?id=3518 Pharo image: Pharo-1.1.1-- Pharo core version: Latest update: #11414 Virtual machine used: Squeak 3.11.4 (beta) from Aug 27 2009 Steps to reproduce: " Set the environment to warn the user about parsing exceptions " Parser warnUser. Parser warningAllowed = true or: [self error]. Transcript open. " Let's signal the exception " Compiler evaluate: 'a'. " Now set the silent behavior " Parser silent. Parser warningAllowed = false or: [self error]. " But the exception still notifies the user " Compiler evaluate: 'b'. [Compiler evaluate: 'b'] on: UndeclaredVariableWarning do: [:ex | self error] because of this if you want to compile programatically without user intervention you must handle every compilation warning like: [ Compiler new compile: aString classified: aCategoryClassification ] on: UndeclaredVariableWarning do: [: ex | self log: 'Warning UndeclaredVariableWarning in ' , self targetClass asString , '>>' , aString asString ] Proposed fix is attached. However you should 1) Take care because #undeclared is trying to do 2 things: a) Handling the interactive and non-interactive user notification. b) Handling the Undeclared global behavior. 2) Review what default behavior do you want. Should the warningAllowed cover the requestor interactive too? 3) Consider implementing two preferences : logging preferences and notifying preferences (they are not the same). I guess it's for the long term when a good logging framework is going to be integrated in the system. Attachments: Encoder-undeclared.st 1.0 KB