Larry Bates wrote: > Claudio Grondi wrote: > >>(just wanted to share my experience with IronPython 1.0) >> >>The context: >> C:\IronPython> ipy.exe >> IronPython 1.0.60816 on .NET 2.0.50727.42 >> Copyright (c) Microsoft Corporation. All rights reserved. >>vs. >> C:\Python24> python.exe >> Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] >>on win32 >> >>IronPython raises "UnboundLocalError: local variable 'strData' >>referenced before assignment" error in following case: >><code> >> while(someCondition): >> try: >> strData = strSomeValue() >> except: >> pass >> if( type(strData) == str ) : ### <<< HERE THE ERROR >> doSomething() >></code> >>CPython 2.4.2 doesn't raise an error with same code. >> >>As strData is not set anywhere before in the code it seems, that >>IronPython is somehow right, but I am not sure if it is a bug or a feature. >> >>Another problem with IronPython where CPython 2.4.2 runs ok was while I >>was trying to do: >> f = file(r'\\.\PhysicalDrive0', 'rb') >>getting "ValueError: FileStream will not open Win32 devices such as disk >>partitions and tape drives. Avoid use of "\\.\" in the path." >>Here the same - I am not sure if it is a bug or a feature. >> >>Can someone knowledgeable elaborate on it a bit please? >> >>Claudio Grondi > > > Your problem is a blanket exception handler that ignores > the exception. Blanket exceptions are almost always a > bad idea. Blanket exceptions with pass as the only > command in the except: block is ALWAYS a bad idea. > > Basically the line strData = strSomeValue() caused an > exception. Since it was inside a try: block, it then > executed what was in the except: block. Since all that > was in the except: block was pass, it just fell through > to the if statement. At that point strData is not > defined because the try block failed and never create > strData object. > > It is doing EXACTLY what you told it to do. Sorry for the confusion caused, but you are right. The actual code was a bit more complex, so I tried to get it down to the principle, but haven't expected, that f = file(r'\\.\PhysicalDrive0', 'rb') buried within strSomeValue() throws an exception as in CPython the code was running ok. So the second problem was the cause also for the first one ... I also erroneously assumed, that the first problem was detected during parsing ... so, by the way: how can I distinguish an error raised while parsing the code and an error raised when actually running the code?
Claudio Grondi -- http://mail.python.org/mailman/listinfo/python-list