http://gwt-code-reviews.appspot.com/77810/diff/34/1016 File user/src/com/google/gwt/core/client/impl/Impl.java (right):
http://gwt-code-reviews.appspot.com/77810/diff/34/1016#newcode148 Line 148: _ = jsFunction.apply(thisObj, arguments); Nasty. Yeah, cromwellian, or maybe spoon. http://gwt-code-reviews.appspot.com/77810/diff/34/1016#newcode163 Line 163: if (hasEntered) { On 2009/10/13 19:26:24, bobv wrote: > When we did the emulated JS stack trace work, we decided to treat the reentrancy > situation as though it were one big stack. I think the same thing applies here. That's fine for JS stack, but it's not fine for Uncaught EH. You really have to fire the Uncaught EH *even in the reentrancy case* because if you're inside a new event loop, the exception *won't* propagate to the outer stack, the browser will swallow / report it. > Re: FinallyCommand, the way Joel and I have been defining it, it's spec'ed to > execute after all use code, but just before we release back to the browser's > event queue. In my mind, that means that FinallyCommands enqueued in reentrant > case execute in the same batch as those enqueued in the outermost execution > context. That makes complete sense, but I don't think it should be handled the same way as Uncaught EH. (That's why I make vague noise about moving it down into the FinallyCommand implementation, but I didn't think through it much and I guess you'd have to call something like FinallyCommand.enter() so it could do its own internal stack tracking.) http://gwt-code-reviews.appspot.com/77810 --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
