On Wed, Feb 4, 2009 at 9:40 PM, Paolo Bonzini <span dir="ltr"><<a href="mailto:bonzini@gnu.org">bonzini@gnu.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
> Neither do I. Mixing #ensure: and continuations is a sure way to get<br>
> either leaks or doubly released objects (which means either exceptions,<br>
> or bugs too-much-reminding-of-C).<br>
><br>
> That seems like "conventional wisdom" to me again. Obviously you can run<br>
> into problems depending on what you put in your ensure block. But I<br>
> don't yet see that:<br>
><br>
> self inform: 'foo'.<br>
> self releaseAnObject<br>
><br>
> is any less likely to cause doubly released objects than<br>
><br>
> [self inform: 'foo'] ensure: [self releaseAnObject]<br>
<br>
</div>Of course, but then the ensured block (the argument) is *not* ensured in<br>
practice (just invoked after the #inform: answers), which makes the<br>
latter form actually confusing.<br>
<div><div></div><div class="Wj3C7c"></div></div></blockquote><div><br>Yes, you're right. Avi pointed this out to me on IM as well and this was the piece I hadn't considered. I wasn't thinking about the case where the web app user never finishes executing of the block of code. I now get that your argument is that calling ensure blocks on every request is a lesser evil than possibly never calling them, which is certainly a reasonable position to take.<br>
<br>Is it a problem then that currently<br><br>[ self call: a ] ensure: [ self foo ]<br><br>results in the ensure block being run on call but with<br><br>[ self answer: b ] ensure: [ self foo ]<br><br>the ensure block will not be run?<br>
<br><br>Julian<br></div></div>