On Thu, Oct 6, 2011 at 6:04 PM, Terry Reedy <firstname.lastname@example.org> wrote:>>> ... try/except blocks are routinely used for flow control in Python
> On 10/6/2011 4:32 PM, Jim Jewett wrote:
>> On Wed, Oct 5, 2011 at 5:17 PM, Terry Reedy<email@example.com> 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.
>>> ... even advocate using them over if/else (leap first)
Only for something that is truly an unexpected error. Bad or missing
>> 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.
data should not prevent the program from processing what it can.
When I want an inline catch, it always meets the following criteria:
(a) The "exception" is actually expected, at least occasionally.
(b) The exception is caused by (bad/missing/irrelevant...) input --
nothing is wrong with my computational environment.
(c) I do NOT need extra user input; I already know what to do with it.
Typically, I just filter it out, though I may replace it with a
placeholder and/or echo it to another output stream instead.
(d) The algorithm SHOULD continue to process the remaining (mostly good) data.
Sometimes, the "bad" data is itself in a known format (like a "."
instead of a number); but ... not always.
Python-ideas mailing list
May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html