Skip to Content

The exception will proceed immediately to the next frame in the call stack, if not caught. It also provides a possibility to carry a potential return value. Finally, I am writing a second helper method which utilizes the forEach helper:

The helper simply calculates whether the first Object is followed by the second one in the collection (irrespective whether this makes sense on a plain Collection; it is just to illustrate the usage). The forEach method is called with an anonymous inner class, which is the rough analogue to a closure. The non-local return is simulated with the NonLocalReturn Exception. When the Exception is thrown, control flow immediately is propagated from the transform method to the followOn method without any further execution within the forEach method. This non-local return might easily break code in forEach, as indicated by the comments there. If, prior to calling transform a resource is opened which must be closed before returning from the method, the client code broke the API code with a non-local return.

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Neal Gafter
    The closures proposal does not undermine finally blocks.  A finally block is still executed when you leave the try block of a try-finally statement, event if you leave it by virtue of a return, break, or continue appearing in a closure that you invoke.
    (0) 
    1. Richard Birenheide Post author
      Hi Neal,

      thanks for the clarification. I shouldn’t have overlooked that.

      Some mixed feelings still remain, since non-local returns encourage practices which I with conventional Java would have considered as bad practice (like enforcing non-local returns by use of exceptions). As blogged before, I am viewing this as being a member of a large team – a very large team – consisting of almost thousand developers. In such an environment, productivity of a developer is not restricted by language constructs, but by communication processes. These can be minimized, if the code base has sufficient readability, maintainability and extensability. One of the benefits I always admired with Java how it encourages (maybe unconciously) developers to write code which meets these goals better than any other language I encountered so far. I prefer very much the possibility to understand coding statically, i.e. without running it, which is supported very well by Java. I always found it to be difficult to read coding incorporating anonymous inner classes and I try to avoid it whenever it exceeds a few lines of code. It is easy to forget about the context the anonymous code is running in, when you read it. As a result I view productivity less in saving a few key strokes but more in ease of reading and absence of surprising behaviour at runtime.

      Kindest Regards

      Richard

      (0) 

Leave a Reply