On Thu, Dec 31, 2009 at 11:47 PM, Peng Yu <pengyu...@gmail.com> wrote: > I observe that python library primarily use exception for error > handling rather than use error code. > > In the article API Design Matters by Michi Henning > > Communications of the ACM > Vol. 52 No. 5, Pages 46-56 > 10.1145/1506409.1506424 > http://cacm.acm.org/magazines/2009/5/24646-api-design-matters/fulltext > > It says "Another popular design flaw—namely, throwing exceptions for > expected outcomes—also causes inefficiencies because catching and > handling exceptions is almost always slower than testing a return > value." > > My observation is contradicted to the above statement by Henning. If > my observation is wrong, please just ignore my question below. > > Otherwise, could some python expert explain to me why exception is > widely used for error handling in python? Is it because the efficiency > is not the primary goal of python? > -- > http://mail.python.org/mailman/listinfo/python-list >
Read the quote again "Another popular design flaw—namely, throwing exceptions *for expected outcomes*" In Python, throwing exceptions for expected outcomes is considered very bad form (well, except for StopIteration but that should almost never be handled directly by the programmer). To answer why people recommend using "Easier to Ask Forgiveness than Permission" as opposed to "Look Before You Leap" : Because of the way it's implemented, Python works quite differently from most languages. An attribute look-up is rather expensive because it's a hash table look-up at run time. Wrapping a small piece of code in a try block however, isn't (relatively) very expensive at all in Python. It's only catching the exception that's expensive, but if you're catching the exception, something has gone wrong anyway and performance isn't your biggest issue. -- http://mail.python.org/mailman/listinfo/python-list