Comparison with False - something I don't understand

[Tim Harig]

On 2010-12-05, Harishankar <v.harishankar at gmail.com> wrote:
>> Or consider this code:
>> 
>> if y != 0:
>>     result = x/y
>> else:
>>     handle_division_by_zero()
>> 
>> 
>> This is also unsafe unless you know the type of y. Suppose y is an
>> interval quantity that straddles zero, then division by y may fail even
>> though y != 0.
>
> Of course in each of these cases the in-built exceptions are used to 
> verify the result of certain system level or lower level operations. My 
> object was not to deprecate the system-level or other low level 
> exceptions thrown by Python, but to consider whether such a mechanism 
> would be a preferable method of handling your own programs error-
> conditions. 

Whether you happen to like the exception mechanism and syntax or not, it is
the idiomatic way of handling errors in Python.  Using two different
conventions in your code will lead to confusion.  I come from a long C
background as well.  I have come to appreciate the power the Python's
exception handling provides.  It does everything that you need to do with
passing values in C and more.

> The issue to be considered by every programmer is to define what can be 
> defined as the exceptional condition and what is a condition that merits 
> merely different treatment without causing disruption of the normal flow 
> of the program.

That is an issue much harder to define.  Anything it is an obvious
error *should* throw an exception.  Invalid input is an error.
Unusable hardware states are errors.  Any invalid request to an object,
is an error.  Essentially anything that deviates from a normal flow of
a program, to handle an exceptional condition, is an error

Where it becomes less obvious is when you start using exceptions as
part normal control flow.  An example is a try it and see methodology.
You might for instance have a group of file objects which might or might
not support a particular method attribute.  You might have a preference for
using the attribute; but, have a fallback plan if it does not.  One way to
handle this is to try to use the attribute and catch the exception raised
if it is not present to execute your backup method.  I have found this
*essential* in some marsaling enviroments where you might not have access to
the meta-data of the object that you are working with.

Another, questionable but useful use, is to ignore the complex accounting
of your position inside of a complex data structure.  You can continue
moving through the structure until an exception is raised indicating
that you have reached a boundary of the structure.

Whether you accept uses of exceptions like these is more of a personal
quesion.  Like many good tools, they can be useful in ways that they were
never really designed to be and I would hate to proclude some of these
really useful features.

This can, of course, be easily abused.  I was once writing code, involving
complex object marshaling like I described above, with a partner who
wasn't totally familiar with Python.  We came to a situation where it
was impossible to know ahead of time what kind of object (one of two
possiblities) we would receive from another marshalled object and had no
meta-data to be able to figure out before attempting to access the object.
I used a try/except clause to resolve the problem.  The next day, I
found several poorly conceived try/except blocks in the codebase that
my partner had used for control structures using dictionaries because
he didn't know of dict.has_key().  I was not so pleased.