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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
