On 10/6/2011 4:32 PM, Jim Jewett wrote:
On Wed, Oct 5, 2011 at 5:17 PM, Terry Reedytjreedy@udel.edu wrote:
On 10/4/2011 10:21 PM, Guido van Rossum wrote:
We also have str.index which raised an exception, but people dislike writing try/except blocks.
Given that try/except blocks are routinely used for flow control in Python, and that some experts even advocate using them over if/else (leap first), I am tempted to ask why such people are using Python. I am curious, though, why this exception is more objectionable than all the others
str.index is a "little" method that it is tempting to use inline, even as part of a comprehension.
That is an argument *for* raising an exception on error. If one uses .find or .index in a situation where success is certain, then it does not matter what would happen on failure. If failure is possible, and users are tempted to skip checking, then the interpreter should raise a fuss (exception), as it does for other 'little' methods like arithmetic and subscript operations.
a.find(b) can raise an AttributeError or TypeError, so returning -1 instead of raising ValueError only partly avoids possible exceptions.
There isn't a good way to handle exceptions without a full statement.
Neither is there a good way to handle error return values without a full statement. The try/except form may require fewer lines than the if/else form.