Confirmed users
497
edits
Debugger: Difference between revisions
Jump to navigation
Jump to search
→Properties of the Debug Prototype Object: Pass frames to breakpoint and watchpoint handlers. Let them specify how execution should continue.
(Clarify descriptions of functions that operate on lexical environments.) |
(→Properties of the Debug Prototype Object: Pass frames to breakpoint and watchpoint handlers. Let them specify how execution should continue.) |
||
| Line 66: | Line 66: | ||
<dt>setBreakpoint(<i>script</i>, <i>offset</i>, <i>handler</i>) | <dt>setBreakpoint(<i>script</i>, <i>offset</i>, <i>handler</i>) | ||
<dd>Set a breakpoint at the bytecode instruction at <i>offset</i> in <i>script</i> | <dd>Set a breakpoint at the bytecode instruction at <i>offset</i> in <i>script</i>, reporting hits to the function <i>handler</i>. This call replaces any existing breakpoint at the given location. | ||
When execution reaches the given instruction, SpiderMonkey calls <i>handler</i>, passing a <code>Debug.Frame</code> instance representing the currently executing stack frame. The handler method's return value determines how execution should continue: | |||
<ul> | |||
<li>If it returns true, execution continues normally. | |||
<li>If it returns an object of the form <code>{ throw: <i>value</i> }</code>, then <i>value</i> is thrown as an exception from the current bytecode instruction. <i>value</i> must be a debuggee value. | |||
<li>If it returns null, the calling code is terminated, as if it had been cancelled by the "slow script" dialog box. | |||
</ul> | |||
Breakpoint handler calls are cross-compartment, intra-thread calls: <i>handler</i> must be a function in the debugger's compartment (and thus calls to it take place in the debugger's compartment), and the call takes place in the same thread that hit the breakpoint. | Breakpoint handler calls are cross-compartment, intra-thread calls: <i>handler</i> must be a function in the debugger's compartment (and thus calls to it take place in the debugger's compartment), and the call takes place in the same thread that hit the breakpoint. | ||
| Line 84: | Line 91: | ||
<dl> | <dl> | ||
<dt>add(<i>descriptor</i>) | <dt>add(<i>frame</i>, <i>descriptor</i>) | ||
<dd>A property named <i>name</i> has been added to <i>object</i>'s referent. <i>Descriptor</i> is a property descriptor of the sort accepted by <code>Object.defineProperty</code>, giving the newly added property's attributes. | <dd>A property named <i>name</i> has been added to <i>object</i>'s referent. <i>Descriptor</i> is a property descriptor of the sort accepted by <code>Object.defineProperty</code>, giving the newly added property's attributes. | ||
<dt>delete() | <dt>delete(<i>frame</i>) | ||
<dd>A property named <i>name</i> has been deleted from <i>object</i>'s referent. | <dd>A property named <i>name</i> has been deleted from <i>object</i>'s referent. | ||
<dt>change(<i> | <dt>change(<i>frame</i>, <i>oldDescriptor</i>, <i>newDescriptor</i>) | ||
<dd>The existing property named <i>name</i> on <i>object</i>'s referent has had its attributes changed to those given by <i> | <dd>The existing property named <i>name</i> on <i>object</i>'s referent has had its attributes changed from those given by <i>oldDescriptor</i> to those given by <i>newDescriptor</i>. | ||
<dt>set(<i>value</i>) | <dt>set(<i>frame</i>, <i>value</i>) | ||
<dd>The property named <i>name</i> | <dd>The property named <i>name</i> is about to have <i>value</i> assigned to it. The assignment has not yet taken place, so the debugger can use <i>getOwnPropertyDescriptor</i> to find the property's pre-assignment value (assuming it is not an accessor property). This call takes place whether the property is a data or accessor property, even if the property is not writable or lacks a setter. This call takes place even if the property is a value property and <i>value</i> is identical to its current value. | ||
<dt>get() | <dt>get(<i>frame</i>) | ||
<dd>The property named <i>name</i> is about to be read. This call takes place whether the property is a data or accessor property, even if the property lacks a getter. | <dd>The property named <i>name</i> is about to be read. This call takes place whether the property is a data or accessor property, even if the property lacks a getter. | ||
</dl> | </dl> | ||
In all cases, the method's <i>frame</i> argument is the current stack frame, whose code is about to perform the operation on the object being reported. | |||
The handler method's return value determines how execution proceeds, as described below for the <code>interrupt</code> hook function. Furthermore, <code>set</code> may return an object of the form <code>{ value:<i>newValue</i> }</code>, indicating that the property should have <i>newValue</i> assigned to it instead of the <i>value</i> passed to <code>set</code>. | |||
If a given method is absent from <i>handler</i>, then events of the given sort are ignored. The watchpoint retains a reference to the <i>handler</i> object itself, and consults its properties each time an event occurs, so adding methods to or removing methods from <i>handler</i> after setting the watchpoint enables or disables reporting of the corresponding events. | If a given method is absent from <i>handler</i>, then events of the given sort are ignored. The watchpoint retains a reference to the <i>handler</i> object itself, and consults its properties each time an event occurs, so adding methods to or removing methods from <i>handler</i> after setting the watchpoint enables or disables reporting of the corresponding events. | ||