Hi Karl, thanks for this mail, Karl Dahlke wrote on Fri, Jan 19, 2018: > 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:
The problem I have isn't that 'x.foobar is undefined' but the error is often: TypeError: undefined not callable (property 'something' of [object Object]) That does not tell you the name of the variable to inspect, so you have to go back to code. > 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. I have that in my branch, but do not offer the ability to do much from the pause at this point -- this shouldn't be too hard to extend though if we can catch what 'x' is. What I'd like to make work is: - plug debugger - run with demin - on error give a prompt - from prompt give possibility to 'list' lines from the script around current line (kind of like gdb), to eval variables like jdb but through the debugger eval command Just that should help greatly; I'm still missing the last part but shouldn't be too difficult at this point... -- Dominique _______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
