<div dir="ltr"><div class="gmail_quote"><br><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><pre><code>____def process_todo(todo):
</code><code><code>____</code></code><code><code>____</code>pre_process()
</code><span><code><code><code>____</code></code></code><code><code><code>____</code></code></code><code><code><code></code></code>for t in todo:
</code><code><code><code><code>____</code></code></code><code><code><code>________exc</code></code></code><code><code><code></code></code></code></code><code><code><code><code></code></code></code><code><code><code></code></code></code>ept Exception, e:
</code></span><code><code><code><code>_</code></code></code><code><code><code>___</code></code></code></code><code><code><code><code>_</code></code></code><code><code><code>___</code></code></code></code><code><code><code><code>_</code></code></code><code><code><code>___</code></code></code></code><code><code><code><code>_</code></code></code><code><code><code>___</code></code></code>break</code>
<code><code><code><code>_</code></code></code><code><code><code>___</code></code></code></code><code><code><code><code>_</code></code></code><code><code><code>___</code></code></code></code><code><code><code><code>_</code></code></code><code><code><code>___</code></code></code>process(t)
</code><code><code><code><code>_</code></code></code><code><code><code>___</code></code></code></code><code><code><code><code>_</code></code></code><code><code><code>___</code></code></code>post_process()    


As an alternative to 

</code><code>____def process_todo(todo):
</code><code><code>____</code></code><code><code>____</code>pre_process()
</code><code><code><code>____</code></code></code><code><code><code>____</code></code></code><code><code><code></code></code>for t in todo:
</code><code><code><code><code>____________try
</code></code></code></code><code><code><code><code><code><code><code><code>_____</code></code></code><code><code><code>___</code></code></code></code><code><code><code><code>_</code></code></code><code><code><code>___</code></code></code></code><code><code><code><code>_</code></code></code><code><code><code>___</code></code></code>process(t)
</code>____</code></code></code><code><code><code>________exc</code></code></code><code><code><code></code></code></code></code><code><code><code><code></code></code></code><code><code><code></code></code></code>ept Exception, e:
</code><code><code><code><code>_</code></code></code><code><code><code>___</code></code></code></code><code><code><code><code>_</code></code></code><code><code><code>___</code></code></code></code><code><code><code><code>_</code></code></code><code><code><code>___</code></code></code></code><code><code><code><code>_</code></code></code><code><code><code>___</code></code></code>break</code>
<code><code><code><code>_</code></code></code><code><code><code>___</code></code></code></code><code><code><code><code>_</code></code></code><code><code><code>___</code></code></code>post_process()    
</code></pre></div></blockquote><div><br></div></span><div>I don't feel former is quite readable than later. </div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><pre></pre>
    <p>Of course, a couple `try` nested statements make the indentation
      worse.  For example, we wish to ignore problems in dealing with
      todo items, like above, but the todo items are complicated; each
      is a dict() of details.  Failure to deal with one of the details
      is ignored, but the rest of the details are still attempted: </p>
    <pre><code>def process_todo(todo):
____pre_process()
____for t in todo:
________except Exception, e:
____________break
________for u, v in t.items():
____________except Exception, e:
________________continue 
____________process()
____post_process()   

Which is better than what I do now:

def process_todo(todo):
____pre_process()
____for t in todo:
________try:
____________for u, v in t.items():
________________try:
____________________process()
________________except Exception, e:
____________________continue 
________except Exception, e:
____________break
____post_process()   
</code></pre>
    <br></div></blockquote><div><br></div></span><div>While later is more nested, it seems straightforward.</div><div><br></div><div>Additionally, try-catch pair should have minimum try block unlike try-finally pair.</div><div>I am afraid of proposed syntax sugar misleads people to expand try block.</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><p><code>At a high level:  The `try/except/finally` is powerful
        structure.  Realizing that the `try/finally` pair is very common
        leads to the creation of `with`. I am proposing the same logic
        for `try/catch` pair:  They are commonly paired together and
        should have an optimized syntax. </code></p>
    <p><code></code><code></code></p>
    <pre><code></code></pre></div></blockquote></span><div>try-catch pair shouldn't used so many like try-finally pairs.</div><div><br></div><div>When function call is very nested, only function near top level should catch Exceptions.</div><div>Most of middle~bottom level functions use only finally (or with statement, off course).</div><div><br></div><div>If many functions have catch clause, it's a very bad code smell.</div><div><br></div><div>C# and Java have syntax sugar only for try-finally pair too.</div><div>(using statement in C# and try with resource in Java).</div></div></div></div></div><br clear="all"><div><br></div>-- <br><div class="gmail_signature">INADA Naoki  <<a href="mailto:songofacandy@gmail.com" target="_blank">songofacandy@gmail.com</a>></div>
</div>