Comparison with False - something I don't understand

[Harishankar]

On Thu, 02 Dec 2010 07:35:18 -0800, Stephen Hansen wrote:

> Exceptions aren't about "error management"; they are about exceptional
> conditions: some are errors, others are entirely normal situations you
> know are going to happen (such as reaching the end of a sequence as you
> iterate over it: that's not an error, but it is special). To be
> philosophically opposed to them seems to me to be philosophically in
> favor of race conditions.

Maybe I worded that part wrongly. Of course I get that error handling is 
only a part of exception mechanism. I agree that the built-in exceptions 
are useful but I prefer most times not to catch them. :-)

> ? How do they destroy clarity or add clutter, since presumably you have
> to deal with that "False" in some way with logical structure -- which
> always does whitespace in Python. If not immediately, then up the call
> stack (which seems to imply you should just not use a try/except and let
> the exception unwind the stack to wherever in your code someone wants to
> deal with it).

The reason why I said they remove clarity is because it's not always 
obvious at which point the exception may be raised. In other words, 
within a try block there may be multiple statements that generate the 
exception. Of course, as I said before, one way would be to wrap single 
statements with the try block and avoid this issue.

> 
> if is_correct():
>     result = do_thing()
> else:
>     do_error_handling()
> 
> try:
>     result = do_thing()
> except KeyError:
>     do_error_handling()

Of course, to me the if statement would make more sense because I 
immediately figure out the exact condition being tested against while the 
exception object is not always so clear and maybe ambiguous in some 
cases. 

Also if that same type of exception is raised by another statement within 
a function that is called within the try block then it would be handled 
by the same except block right? This is where it gets a bit confusing to 
me and the flow of code is not always obvious. That's why I prefer atomic 
error handling where I know exactly which part of the code led to the 
result.

> And as an aside, the more statements one puts into a try/except block:
> and the more complicated a statement at that-- the more likely it is
> they are going to mess up and do something Wrong.
> 
> Now, all that said: sure, in some situations I do prefer the "check
> first" style of programming where exceptions don't end up being used.
> Its not *wrong* to return False on an "error condition": its going
> against the grain, though, and makes your code harder to deal with
> long-term if only because now there's two separate mechanisms that
> "errors" happen in it.

I realize that it is impossible for me to avoid exception mechanism 
myself. So I restrict it only to situations where I cannot avoid it (e.g. 
inbuilt exceptions in some cases where I want to handle it myself)


> 
> You can't totally do away with exceptions in Python, even if you try
> very hard. So with that in mind, IMHO, the best approach is to just...
> get over it, and learn to appreciate them :)

Finding it hard to appreciate exceptions myself. But I am used to 
thinking linearly. A piece of code which does not explain itself in the 
most obvious way even if I wrote it always worries me.

-- 
Harishankar (http://harishankar.org http://lawstudentscommunity.com)