[Edbrowse-dev] Error Object

[Karl Dahlke <eklhad@comcast.net>]

[-- Attachment #1: Type: text/plain, Size: 2507 bytes --]

My note to Sami, and his reply.

==================================================

We find that debugging our browser is notoriously difficult, partly because it's hard to get our hands on real information.
When an error occurs in javascript, it probably shouldn't, it probably happened because our DOM is incomplete, so we need to track it down.

1. error has file and line number, but js in the wild is often minimized, all contained on one line, perhaps 100K long.
Is it possible to include column number in the error object? Even approximate column number? Like compilers do.

2. Errors are usually x.foobar is undefined. We would like to get our hands on x.
Is there any way, through the error object, or even a Duktape.errCreate function, to get a hold of the parent object wherein the property is not defined?
I would at minimum print its nodeName, and perhaps its location within the document tree.
The source is rarely helpful here; it typically says x.foobar, x a parameter to a function, which was another parameter to a function, which was ... on and on.

==================================================

Right now the lexer doesn't track column number information. That's
been requested a few times, so it's quite likely I'll add that support
to the tokenizer and bytecode emitter so that it can be included in
errors. There's nothing technically difficult about it as such, but
for low memory targets it's important to bit pack the column number
information which needs some work.

Re: x.foobar, the base value is unfortunately not available after
error creation. Both expressions like 'v = x.foobar' and 'v =
x.foobar()' do have access to 'x' when the internal call site creates
and throws the error. So it would be technically possible to include
the base value as a property of the error object before it gets
thrown. That would be an entirely custom feature though, and would
capture the base value (maybe keeping it live for longer than
expected). One option would be to pass in the base value into
Duktape.errCreate using some form of "additional parameters" object,
e.g. equivalent of:

augmented = Duktape.errCreate(err, { baseValue: x });

When using the debugger, it's possible to pause on uncaught error
(DUK_USE_DEBUGGER_PAUSE_UNCAUGHT), at which point you can inspect 'x'
as a local variable. The internal implementation is capable of pausing
also on caught errors, but the debugger protocol doesn't expose this yet.


Karl Dahlke