On 7 October 2011 20:18, Jim Jewett <jimjjewett@gmail.com> wrote:
On Thu, Oct 6, 2011 at 6:04 PM, Terry Reedy <tjreedy@udel.edu> wrote:
> On 10/6/2011 4:32 PM, Jim Jewett wrote:
>> On Wed, Oct 5, 2011 at 5:17 PM, Terry Reedy<tjreedy@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.

>>> ... try/except blocks are routinely used for flow control in Python
>>> ... even advocate using them over if/else (leap first)

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

Only for something that is truly an unexpected error.  Bad or missing
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.

Yeah, I've quite often worked on data sets where you just need to process what you can and ignore (or replace with placeholders) what you can't.

Michael Foord
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