Using catch-all in for-loops with "return" can lead to surprises

[sjmackenzie]

It is possible to catch the exceptions that are used by the implementation of the (experimental?) "return"
feature of the for-loop. If this is done unintentionally, it can lead to hard-to-find bugs.

Example:

declare

fun {DivideBy X}
   42 div X
end

fun {Loop Fun}
   for I in [0 1 2 3] default:thisShouldNeverBeReturned return:R do
      try
         {R {Fun I}}
      catch E then
         skip
      end
   end
end

in
{Show {Loop DivideBy}}

The expected result is: 42
The actual result is: thisShouldNeverBeReturned

Possible strategy for fix: Let the for-loop implementation use a special kind of exception that can never be catched
by user code? (No idea whether this can be implemented, though.).

[doublec]

The same problem exists with 'break' and 'continue' - these are mentioned in the documentation though whereas the issue with 'return' is not.