638
edits
Debugger tests: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 20: | Line 20: | ||
var dbg = new Debugger(g); | var dbg = new Debugger(g); | ||
... | This automatically turns on debug mode for the target compartment, so the <code>-d</code> option is unnecessary. Hooray! | ||
Debugger statements are extremely useful for testing the debugger. This is actually a standard part of the ECMAScript language: a debugger statement looks like this: <code>debugger;</code> an when it executes, the behavior is implementation-defined. In our case, it fires an <code>onDebuggerStatement</code> event. So we set a handler for that event: | |||
var c; | var c; | ||
| Line 26: | Line 28: | ||
c = frame.eval("2 + 2"); | c = frame.eval("2 + 2"); | ||
}; | }; | ||
'''Warning:''' By design, exceptions are never automatically propagated from debugger code to the debuggee. | |||
* A few debugger callbacks, like <code>onNewScript</code>, squelch all exceptions!! It’s useless to call <code>assertEq</code> from such callbacks, because even if the assertion fails, the exception will be silently discarded, and the test will pass anyway. Instead, store the information you need and check it later. | |||
* Throwing from any other debugger callbacks, including <code>onDebuggerStatement</code>, will terminate the debuggee with an uncatchable error. So it is OK to call <code>assertEq</code> from <code>onDebuggerStatement</code>. Both jit_test.py and jstests.py will treat that as a test failure. | |||
g.eval("debugger;"); | g.eval("debugger;"); | ||
assertEq(c.return, 4); | assertEq(c.return, 4); | ||