On Thu, Dec 31, 2009 at 11:47 PM, Peng Yu <pengyu.ut at 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.