638
edits
Debugger: Difference between revisions
→Debugger Handler Functions: finally blocks don't always complete normally
(Update to correctly describe globals-as-debuggees model. Use 'method', not 'hook', except for uncaughtExceptionHook. Describe multi-debugger behavior. Define 'visible frames'. Clarify and reorganize.) |
(→Debugger Handler Functions: finally blocks don't always complete normally) |
||
| Line 158: | Line 158: | ||
<dd>The exception <i>value</i> has been thrown, and has propagated to <i>frame</i>; <i>frame</i> is the youngest remaining stack frame, and is a debuggee frame. This method should return a [[#Resumption_Values|resumption value]] specifying how the debuggee's execution should proceed. If it returns <code>undefined</code>, the exception continues to propagate as normal: if control in <code>frame</code> is in a <code>try</code> block, control jumps to the corresponding <code>catch</code> or <code>finally</code> block; otherwise, <i>frame</i> is popped, and the exception propagates to <i>frame</i>'s caller. | <dd>The exception <i>value</i> has been thrown, and has propagated to <i>frame</i>; <i>frame</i> is the youngest remaining stack frame, and is a debuggee frame. This method should return a [[#Resumption_Values|resumption value]] specifying how the debuggee's execution should proceed. If it returns <code>undefined</code>, the exception continues to propagate as normal: if control in <code>frame</code> is in a <code>try</code> block, control jumps to the corresponding <code>catch</code> or <code>finally</code> block; otherwise, <i>frame</i> is popped, and the exception propagates to <i>frame</i>'s caller. | ||
When an exception's propagation causes control to enter a <code>finally</code> block, the exception is temporarily set aside. | When an exception's propagation causes control to enter a <code>finally</code> block, the exception is temporarily set aside. If the <code>finally</code> block finishes normally, the exception resumes propagation, and the debugger's <code>onExceptionUnwind</code> handler is called again, in the same frame. (The other possibility is for the <code>finally</code> block to exit due to a <code>return</code>, <code>continue</code>, or <code>break</code> statement, or a new exception. In those cases the old exception does not continue to propagate; it is discarded.) | ||
<dt>sourceHandler(<i>ASuffusionOfYellow</i>) | <dt>sourceHandler(<i>ASuffusionOfYellow</i>) | ||