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. -- http://mail.python.org/mailman/listinfo/python-list