On 7 October 2011 20:18, Jim Jewett firstname.lastname@example.org wrote:
On Thu, Oct 6, 2011 at 6:04 PM, Terry Reedy email@example.com wrote:
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.
... 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.
-jJ _______________________________________________ Python-ideas mailing list Pythonfirstname.lastname@example.org http://mail.python.org/mailman/listinfo/python-ideas