Comparison with False - something I don't understand

[Tim Harig]

On 2010-12-03, Harishankar <v.harishankar at gmail.com> wrote:
> On Thu, 02 Dec 2010 16:52:57 +0000, Tim Harig wrote:
>
>> 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.
>
> I think I might very well by using try blocks rather defensively rather 
> than letting the code reach its logical conclusion in normal 
> circumstances. This is why I think I find it a bit clunky. 

That was the conclusion I was coming to.

> I think I understand the general trend of what you're saying. It 
> definitely requires a mindset change. I still feel that user-defined 
> exception classes might not be the way, but maybe I should allow the 
> built-in exceptions which are thrown by library functions to follow its 
> natural path upwards till it reaches the top level where it could be 
> handled. 

Look at it this way, in C you were constrained to place your error
handling code around ever function that might fail.  Now you are free
to place the error handling code wherever it makes sense to do so.
As a general rule, if, in C, your function would handle the error by
passing an error return value to the calling function, then the error
handling code should be higher up.

> Maybe I should handle the error only at the highest level (UI level) 
> rather than returning False to flag errors. 

I don't write many UIs; but, I normally consider the UI code to be yet
another subsystem.  In general, I find the best place to place error
handling code in the high level business logic of your application (which
might be what you actually meant by UI, to me the UI code is the code that
actually draws the interface), in the high level logic of the systems,
and in the bounderies between subsystems.  The exceptions caught at each
level depend on where the logic to handle the error is best applied.

> One of the reasons why I feared to do this is because I need to know each 
> and every exception that might be thrown by the function and litter my 
> top-level code with too many exception handlers.

Each exception has a place where it is better handled.  Wherever you
find boundaries between subsystems, think about what error conditions
that subsystem might encounter.  Subsystems dealing with are likely
to encounter io related errors, network subsystems network errors,
parsers validation errors etc.  Logic exceptions that indicate errors
in your code should be left alone entirely so that they may be easily
found. Look at the exceptions pertaining to these subsystems.

For each error reaching the boundery, think about whether you have enough
information within the module to handle the error in a constructive
manner or whether the error handling would benefit from information
further up in the program.  If you have all of the information that you
need then handle it in the main logic of that subsystem.  If not, pass
it up to the error handlers on top of the boundry.  When you get there,
make the same decision.

In general you only need to catch a handful of exceptions at each level.
The easy excpetions will be handled at lower levels.  The most difficult
exceptions will rise towards the top of the program until only the terminal
exceptions, that cannot be resolved are left with the inevitable result that
you should notify the user and exit, will remain.