<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Apr 15, 2017 at 8:34 PM, Yuya Nishihara <span dir="ltr"><<a href="mailto:yuya@tcha.org" target="_blank">yuya@tcha.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, 14 Apr 2017 00:44:08 -0700, Gregory Szorc wrote:<br>
> # HG changeset patch<br>
> # User Gregory Szorc <<a href="mailto:gregory.szorc@gmail.com">gregory.szorc@gmail.com</a>><br>
> # Date 1492155236 25200<br>
> #      Fri Apr 14 00:33:56 2017 -0700<br>
> # Node ID b8a66f70caadbe53bf2ea43b0be1d1<wbr>d8acba94ad<br>
> # Parent  80bd24abcf67d5dc8b5f5bf83c796e<wbr>1f71fc5bd9<br>
> httppeer: wrap HTTPResponse.read() globally<br>
><br>
> There were a handful of places in the code where HTTPResponse.read()<br>
> was called with no explicit error handling or with inconsistent<br>
> error handling. In order to eliminate this class of bug, we globally<br>
> swap out HTTPResponse.read() with a unified error handler.<br>
><br>
> I initially attempted to fix all call sites. However, after<br>
> going down that rabbit hole, I figured it was best to just change<br>
> read() to do what we want. This appears to be a worthwhile<br>
> change, as the tests demonstrate many of our uncaught exceptions<br>
> go away.<br>
<br>
</span>After reading the whole series, I agree. Queued but for the last one, thanks.<br>
<span class=""><br>
> To better represent this class of failure, we introduce a new<br>
> error type. The main benefit over IOError is it can hold a hint.<br>
> I'm receptive to tweaking its name or inheritance.<br>
<br>
</span>How about WireTransportError? RichIOError seems a bit confusing since it<br>
isn't (and shouldn't be) an IOError.<br>
</blockquote></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Yeah, I think renaming it to "WireTransportError" or similar is a good idea. I'll try to send that patch later today...<br></div></div>