On 12/4/2010 12:07 PM, Harishankar wrote:
Of course not. But going by the replies here, it appears that Python has made exceptions as the "norm" for error handling which is ironical considering the meaning of the word "exception".
In communications parlance, 'exception' = out-of-band signal or return value, while 'return'ed value = in-band signal. A fake in-band return value, like returning None (ok) or False (worse) to *signal* 'I cannot return a list' is still an exception signal, even if 'in-band'.
The advantage of out-of-band signals is that they cannot be mistaken for valid in-band signals (return values). If a caller neglects to catch an exception, the process stops, as it should. If a caller neglects to check return values, the process goes on (at least for a while) under the pretense that error codes (in-band exception signals) are valid return values.
Neglecting to check return values for error codes is a common bug in C code. At worst, the process eventually return a bad value or performs a bad action. At best, it crashes sometime later, making the bug hard to find.
Or a function is called without even storing, let alone checking the return value. This is common for i/o functions. A program may 'finish' without any indication that it failed. If one does the same with Python functions (equally common), any exceptions *will* be passed up until either caught or displayed on the screen with an informative traceback (assuming that the screen is the not source of the error).
-- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
