Failure to do so can result in the new exceptions being thrown (and thereby obscuring) an existing exception that has been thrown but not handled yet. It may also mean that the VM will continue running on potentially unstable state, and may have undesirable consequences. I first observed this in some failed assertion while running tests on a patch for https://bugs.webkit.org/show_bug.cgi?id=154865.
Created attachment 273294 [details] x86_64 benchmark result. I did a patch where I changed synthesizePrototype() and JSValue::isObjectSlow() to return a nullptr when they fail and an exception is thrown. With that patch, the perf numbers are neutral. Patch coming soon.
Created attachment 273299 [details] proposed patch.
Comment on attachment 273299 [details] proposed patch. Will rebase bindings test result.
Created attachment 273318 [details] proposed patch 2: with rebased binding test result. This patch has been run on the api tests, binding tests, JSC tests, and layout tests with no regression (AFAIK).
Comment on attachment 273318 [details] proposed patch 2: with rebased binding test result. r=me
Thanks for the review. Landed in r197794: <http://trac.webkit.org/r197794>.