Martin v. Löwis wrote:
Note that using exceptions for control flow can be bad for other implementations of Python. For example exceptions on the .NET framework are very expensive.
Why do you say that? What specific implementation of .NET are you referring to? What do you mean by "very"?
I'm talking about IronPython on the Microsoft .NET framework - although it is likely that the same is true of IronPython on Mono. On the .NET framework the setup for exception handling is virtually free until an exception is raised. Once an exception is raised it takes a lot longer (expensive in time). This means that in IronPython exception handling code (try... except and try... finally blocks) are much faster than CPython if no exception is raised - but much more expensive if an exception is raised. You can see this in a comparison of IronPython 2 and Python 2.5 running PyBench: http://ironpython.codeplex.com/Wiki/View.aspx?title=IP201VsCPy25Perf TryExcept: 26ms 888ms -97.1% 63ms 890ms -92.9% TryRaiseExcept: 58234ms 1286ms +4428.6% 58474ms 1298ms +4404.6%
Isn't it better practise for exceptions to be used for exceptional circumstances rather than for control flow?
This is an ongoing debate (in Python, and outside). I'm in the camp that says that exceptions are a control flow mechanism just like loops, conditionals, and recursion. With exceptions, you get essentially multiple alternative outcomes of a function call, rather than just a single result. In principle, it would be possible to eliminate the return statement altogether, but it is useful syntactic sugar.
Using exceptions for control flow is akin to goto. Sometimes useful but a dubious practise. :-) Michael
Regards, Martin
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog