SRA-SiliconValley/jalangi — pull request #14 by msridhar (2013-12-05 00:56:00+00:00)
Title: Fixing handling of caught exceptions

With the current Jalangi instrumentation strategy, the semantics of programs that catch exceptions may not be preserved. E.g., consider the following example:

```
function foo() { throw "error"; }
...
try {
foo();
} catch (e) {
console.log("caught");
}
```

The instrumentation of `foo()` will "swallow" the thrown exception, so the catch block printing "caught" won't be executed. This seems to be a known issue, since there is a known failing test `tests/unit/try_catch_finally.js` exposing a similar problem.

I ran into this issue while trying to get the jQuery unit tests to pass for an instrumented version of jQuery 2.0.2, as part of debugging an issue with another app. One of the tests checks that an expected exception is thrown, and hence it fails with instrumented code.

The attached patch fixes the issue by adding an `insertOuterWhileLoop` flag to `esnstrument.js`, such that exceptions are not swallowed when that flag is false. Having the flag as false causes symbolic analysis to fail, however. Also, this is still a work in progress; one of the octane tests `code-load` seems to fail with this change.

Anyway, posting the pull request to start a discussion as to what the "right" fix to this issue is. Do we want to somehow only insert the outer while loops and exception-swallowing code for symbolic analysis? Do we really want the symbolic analysis to be swallowing exceptions? Is there some better fix?