Hi. I've implemented nice helper to break out of loops in particular

[alk]

_.withBreak(function ($break) {
  //some code
  $break(<value>) // will make _.withBreak return that value
  //some other code
});

it's almost like call/cc, but of course without full continuations

[jashkenas]

I'm afraid that try/catch isn't a good technique for control flow in JavaScript, and should be avoided if possible. But thanks for the patch.

[alk]

I'm afraid there're no alternatives. Any pointers about badness of control flow via exceptions ?

[jashkenas]

You can try benchmarking it yourself ... the only real pointer is to avoid exceptions in JavaScript except for when you have a true error condition that should crash the app.

[michaelficarra]

Pointer: don't do it ever. It's exceptionally slow (pardon the pun) in pretty much every implementation. Search for the JSperf, it's there somewhere. try/catch should only be used to catch exceptions from externally-defined functions that may throw.

[alk]

Just for the record.

It's not so simple. Lot's of jsPerf benchmarks are so micro and they have unpredictable performance given quality of js jits (see famous post about flawed microbenchmarks from Java folk: http://www.ibm.com/developerworks/java/library/j-jtp02225/index.html ). My point is: be extremely careful when interpreting any benchmark numbers.

Anyway here's what I've got:

http://jsperf.com/for-vs-foreach/9 (shows that forEach is generally order of magnitude slower on FF 3.6 and around same on V8)

http://jsperf.com/for-vs-foreach-with-break/2 (now forEach is 2 times slower than loop on V8 and around same on FF)

Of course as with any benchmarking, screwing up (without even noticing) is so easy. So feel free to correct my benchmarks and be careful believing that numbers.

So at least for my code I'm not going to fanatically avoid throwing. Especially if non-local return is helpful/needed.

[michaelficarra]

In your for-vs-foreach-with-break test, you move the hot-point of your code within the try/catch. It's the entrance and exit of the try/catch that's expensive.

[alk]

Yes. I'm well aware of that. And the problem seems to be allocation of call stack frame on heap, which causes GC pressure, which affects (otherwise malloc-less) micro-benchmark. And that only affects some interpreters.

Keep in mind though, that heap allocation of frames is not that rare event. Any code that creates closures does that by default. Inlining (typical for forEach micro-benchmarks) avoids that.