Comparison with False - something I don't understand

[Tim Harig]

On 2010-12-02, Harishankar <v.harishankar at gmail.com> wrote:
>> Actually, finer grained error handling commonly covers up bugs.  If you
>> want to find bugs, you want to make the program prone to crashing if a
>> bug is present.  It is all too easy to accidently mistake the return
>> value of a function as error condition and handle it rather the letting
>> the program crash.  By separating the results from the transmission of
>> error conditions (in effect taking error conditions out of band) then
>> you make it much harder to make such a mistake because you have to
>> explicity indicate which error conditions your code is capable of
>> generating.
>
> Doesn't the same finer grained exception mechanism make it prone to the 
> same problems? 

Exception handling is a move away from fine grained handling.  If in
IOError is raised by a parser, I don't need to know at exactly which
line the error occured.  All I need to know is that the file is somehow
unreadable; and that is why the parser failed.  Therefore, none of
the parser code should be handling IOError because it is being handled
higher up in the stack.  Since I expected that the parser might have
problemes reading files, for problems that have nothing to do with my
code, I explicity catch that error if it occurs.  I am not expecting an
IndexError from the parser and I don't bother to catch it.  If the parser
code does raise an IndexError, then my program crashes and I know that I
have a bug in the parsing code.  The call trace will tell me where that
error occurs.  I can watch that section of code in debugger to find out
exactly what went wrong.

> Actually return values of functions which I write myself can be as 
> specific and to the point. I could make it as fuzzy or as precise as I 
> like. This is no doubt, something that I could emulate with an exception 
> as well, but only make it slightly more complex with no obvious benefit.

You seem to be making it complex because you are still trying to be too
fine grained in handling each exception where it occurs as opposed to
handing where the logic makes sense that it should be handled and because
you are trying to code too defensively against your own code.  Exception
handling does require a different focus from handling errors from return
values alone.

> As I said before, the way exceptions are caught seem to me to be the most 
> confusing bit. Non-atomic operations always worry me. What if my function 
> which is wrapped inside a try block has two different statements that 
> raised the same exception but for different reasons? With error handling 
> I could probably handle it right below the statement which was called and 
> thus reduce the problem???

If you are having that issue, then you are likely placing the try blocks
at too low of a level in your code.  In general you will find that
most systems have a gateway function as an entry point to the system.
If there is not one already, then create such a function in you code.
The parse function in my code above would be an example of such a
gateway function.  Beneath that function, you don't need to know exactly
where the error occured, you just need to know the nature of the error and
have general error handling procedures for each kind of error that you
expect might occur.