Short Functions

Allen Wirfs-Brock allen at wirfs-brock.com
Wed May 25 23:29:59 PDT 2011


On May 25, 2011, at 7:57 AM, Brendan Eich wrote:

> On May 25, 2011, at 5:30 AM, Lasse Reichstein wrote:
> 
>> 
> 
> 
> "likely" is not for sure. Libraries (e.g. the Array extras such as forEach) are generally not written with finally continuing like that, even in the face of an exception.
> 
> js> function forEach(block) {
>   for (var i = 0; i < this.length; i++) {
>     try {
>       block(this[i]);
>     } finally {
>       // Always iterate to the end!
>       continue;
>     }
>   }
> }
> ...
> 
> This is kind of a trick function. It should be unlikely in practice, among popular libraries.
> 
> But you're right, there are new control effects with block-lambdas not possible with blocks, much more like functions that throw. I've been spelling out block-lambda to avoid these being called "blocks" but I'm probably fighting a strong tide.
> 
> If users and library authors build functional helpers well, then these "blocks" as proposed probably will not bite back so strangely. That seems have been the case in Smalltalk and Ruby and E

I have to say that in all my years doing Smalltalk development and supporting Smalltalk programmers I don't recall every encountering a bug like this.  Smalltalk has both the equivalent of block returns and a "finally" mechanism (which I designed).  I'm pretty sure that if this was a common problem I would have heard about it.

Basically, this is just a buggy code.  The programmer knows they are calling a block that is being used as the "body"  of a control abstraction method and knows that such blocks can contain non-local returns.  They also know the normal user expectation for such such returns.  If given all that they still have a good reason for doing it, then so be it.  But I think that it would be highly unlikely to actually occur as a bug in a forEach method.

More generally, I think this type of abnormal exit from a finally should always be subject to serious scrutiny if you see one.  The stack is being unwound for a reason.  There may be an exception handler out there above you on the all stack that really needs to handle the exception that was thrown by the block.  What makes this foreach think it is ok to unconditionally ignore it.

Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110525/35b23915/attachment-0001.html>


More information about the es-discuss mailing list