make IOError exceptions during POST data read() easy to identify

[J. David Lowe]

This is related to #10046 and #17069. I'm wading into contentious territory, I know ;)

In short, I want to be able to suppress the IOError exceptions that are raised under common, but completely uncontrollable, client conditions e.g. connection abruptly closed. Like others, though, I find it unacceptable to completely suppress IOError exceptions, though -- it's a very broad exception class, and I don't want to hide real bugs.

The attached patch addresses this by catching IOErrors that occur while read()ing POST data, and re-throwing them as a new subclass of IOError.

IMO this would simplify the filtering logic for #17069, and would also enable a narrowly-targeted fix to #10046 (which was closed, essentially, because globally handling IOError isn't appropriate.)

Cc: grahamd and carljm, who are associated with the other two tickets.

[Carl Meyer]

Thanks for the contribution! Sorry for the delay in moving it out of DDN. Approach and patch look reasonable to me. Patch no longer applies cleanly to trunk, needs updating.

[J. David Lowe]

New patch (based on r17492) is attached.

[Carl Meyer]

In [17493]:

Fixed #17277 - Wrap IOErrors raised due to client disconnect in a specific IOError subclass so they can be distinguished from more serious errors. Thanks David Lowe.