<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">On Jan 22, 2019, at 8:28 PM, Steven D'Aprano <<a href="mailto:steve@pearwood.info" class="">steve@pearwood.info</a>> wrote:<br class=""><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div class="">I've been thinking more about this proposal, and realised why I've been <br class="">feeling a slight sense of disquiet about it. I think it encourages an <br class="">anti-pattern of catching too much. (Or at least a code smell.)<br class=""><br class="">Although we're all guilty of violating this principle from time to time, <br class="">in general we ought to surround the minimum amount of code with a <br class="">try...except that we need. Ideally (but rarely possible in practice) we <br class="">want to surround a single operation which might raise at a time.<br class=""><br class=""></div></div></blockquote><div><br class=""></div><div>I ended up at a similar conclusion this morning. I'm wary of enclosing too</div><div>much code in the try block since it makes handling exceptions very difficult</div><div>unless you have a rich hierarchy of exceptions -- something that I also warn</div><div>against. I view the problem of enclosing too much in the try block as an</div><div>extension of an overly broad except block. It makes it nearly impossible to</div><div>know where the exception came from so you cannot handle it safely unless you</div><div>have an exception hierarchy where each exception is raised from a single</div><div>place in the code.</div><div><br class=""></div><div>A similar anti-pattern that I see regularly is to *catch too often* where</div><div>there is a try-catch block every time that a method from another module or</div><div>library is called and the catch portion translates the exception instead of</div><div>handling it. It's interesting that the "exception translator" pattern leads</div><div>to an overly rich exception hierarchy.</div><div><br class=""></div><div>It is interesting that you mention whether the try-catch would wrap __enter__</div><div>or not. The main reason that I am -1 on this proposal is that it introduces</div><div>more ambiguity in what is happening. I was about to write pretty much what</div><div>you have written with regards to the syntax muddying the waters about the</div><div>scope of exception handling especially with regards to the meaning of the</div><div>return value of `context_manager.__exit__`</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">But the alternative is to enshrine in syntax something which *by design* <br class="">guards too much and is a code smell.<br class=""><br class=""></div></div></blockquote></div><div><br class=""></div><div>Very well put ;)</div><div><br class=""></div><div>- dave</div><div><div class=""><span style="line-height: 15px; background-color: rgb(255, 255, 255);" class=""><font face="Helvetica-Light" size="2" class="">--</font></span></div><div class=""><span style="line-height: 15px; background-color: rgb(255, 255, 255);" class=""><font face="Helvetica-Light" size="2" class="">Safe wiring is not something to be learned after the fire trucks have left.</font></span></div></div></body></html>