Properly process try/finally blocks.

Properly process try/finally blocks.

In some circumstances, try/finally block can actually catch the exception:

function f() {
  try {
    throw 42;
  } finally {
    return 0;
  }
}

Therefore when propagating exception to v8::TryCatch, we must be sure
there is no try/finally blocks as well.

When bulding the messages we should be more conservative and expect that
any v8::TryCatch with no JS try/catch in between can potentionally
be the right exception handler.

Plus various minor refactorings.

BUG=1147
TEST=cctest/test-api/TryCatchAndFinallyHidingException, cctest/test-api/TryCatchAndFinally

Committed: http://code.google.com/p/v8/source/detail?r=6809

[antonm, 2011-02-15 17:48:32]

Mads,

may you have a look?

I was considering refactoring and renaming ShouldReportException (make explicit
a part which traverses the stack vs. verbosity), but decided not to do right now
(just lazy)

can_be_exteranlly_caught might be better spelled as may_be_externally_caught

[Mads Ager (chromium), 2011-02-16 09:17:49]

LGTM

http://codereview.chromium.org/6526016/diff/1006/src/top.cc
File src/top.cc (right):

http://codereview.chromium.org/6526016/diff/1006/src/top.cc#newcode938
src/top.cc:938: // When throwing the exception, we found no or another
v8::TryCatch
no or another -> no

http://codereview.chromium.org/6526016/diff/1006/src/top.cc#newcode961
src/top.cc:961: if (handler->is_try_finally()) return false;
In cases where the exception is propagated from the try-finally is that handled
as a separate implicit throw at the end of the finally block?

In that case, please add a comment explaining that if the finally clause does
not eat the exception (by returning for instance) it is rethrown at the end of
the finally block.

http://codereview.chromium.org/6526016/diff/1006/src/top.h
File src/top.h (right):

http://codereview.chromium.org/6526016/diff/1006/src/top.h#newcode264
src/top.h:264: return
Why the extra line? I would probably do:

return ((exception != Failure::...) &&
        (exception != Heap::...));

[antonm, 2011-02-16 11:40:44]

Thanks a lot for review, Mads.  Submitting.

http://codereview.chromium.org/6526016/diff/1006/src/top.cc
File src/top.cc (right):

http://codereview.chromium.org/6526016/diff/1006/src/top.cc#newcode938
src/top.cc:938: // When throwing the exception, we found no or another
v8::TryCatch
On 2011/02/16 09:17:49, Mads Ager wrote:
> no or another -> no

Done.

http://codereview.chromium.org/6526016/diff/1006/src/top.cc#newcode961
src/top.cc:961: if (handler->is_try_finally()) return false;
On 2011/02/16 09:17:49, Mads Ager wrote:
> In cases where the exception is propagated from the try-finally is that
handled
> as a separate implicit throw at the end of the finally block?
> 
> In that case, please add a comment explaining that if the finally clause does
> not eat the exception (by returning for instance) it is rethrown at the end of
> the finally block.

Done.

http://codereview.chromium.org/6526016/diff/1006/src/top.h
File src/top.h (right):

http://codereview.chromium.org/6526016/diff/1006/src/top.h#newcode264
src/top.h:264: return
I find it more aesthetically pleasing to have this parallel structures, but
let's do it your way.

On 2011/02/16 09:17:49, Mads Ager wrote:
> Why the extra line? I would probably do:
> 
> return ((exception != Failure::...) &&
>         (exception != Heap::...));