Comparison with False - something I don't understand

[Mel]

Harishankar wrote:

> 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.

User-defined exception classes are no big deal, and I think they're helpful.  
At the minimum, they're just a few lines in a module, e.g.:

class SumpError (StandardError): '''Errors raised by the SUMP client.'''
class SumpIdError (SumpError): '''The wrong string was returned by an ID 
request.'''
class SumpFlagsError (SumpError): '''Illegal combination of flags.'''
class SumpStageError (SumpError): '''Illegal trigger stage setting.'''

This is from a module to drive some special hardware through a serial 
connection.  At this stage in development, I don't even have try/except 
statements for these.  It's enough that some typo will not silently put the 
hardware into an illegal state, and instead will report

Traceback (most recent call last):
  File "logic_sniffer.py", line 184, in OnDeviceCapture
    set_sump_options (grabber)
  File "logic_sniffer.py", line 21, in set_sump_options
    sump.set_flags (demux=True, filter=True, channel_groups=0x0, 
external=False, inverted=False)	# only 1 channel group
  File "/home/mwilson/sandbox/sump-analyzer/sump.py", line 160, in set_flags
    raise SumpFlagsError
sump.SumpFlagsError

Because these are subclasses of StandardError, they'll be caught by any 
`except StandardError`, which may or may not turn out to be a mistake.

Once development is done, try/except for these will be in some window 
methods as part of a wxPython GUI, several call levels above the code that 
would raise the exceptions, up where a human user would take steps to change 
the way things are being done, or submit a bug report (more likely), or 
something.

> Maybe I should handle the error only at the highest level (UI level)
> rather than returning False to flag errors.
> 
> 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.

The advantage to the exceptions, is that they only need to be recognized and 
caught and handled at the UI level.  They don't have to be recognized and 
passed back up the call chain from level to level till they get to the right 
place -- the way out-of-band error returns have to be.

	Mel.