From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Permerror (mailfrom) identity=mailfrom; client-ip=2001:41d0:1:7a93::1; helo=nautica.notk.org; envelope-from=asmadeus@notk.org; receiver= Received: from nautica.notk.org (ipv6.notk.org [IPv6:2001:41d0:1:7a93::1]) by hurricane.the-brannons.com (Postfix) with ESMTPS id AC3DF787E9 for ; Fri, 19 Jan 2018 12:52:13 -0800 (PST) Received: by nautica.notk.org (Postfix, from userid 1001) id C1A6DC009; Fri, 19 Jan 2018 21:52:09 +0100 (CET) Date: Fri, 19 Jan 2018 21:51:54 +0100 From: Dominique Martinet To: Karl Dahlke Cc: Edbrowse-dev@lists.the-brannons.com Message-ID: <20180119205154.GA7850@nautica> References: <20180019150815.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20180019150815.eklhad@comcast.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [Edbrowse-dev] Error Object X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.25 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2018 20:52:14 -0000 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