From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2001:558:fe21:29:69:252:207:38; helo=resqmta-ch2-06v.sys.comcast.net; envelope-from=eklhad@comcast.net; receiver= Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 3A2AC787EF for ; Fri, 19 Jan 2018 12:08:15 -0800 (PST) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-06v.sys.comcast.net with ESMTP id ccwYe102VKZSMccxUewYLt; Fri, 19 Jan 2018 20:08:16 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1516392496; bh=SZoqRZ7C8afRniTiJkbHr6n9BAjePB7JbrLG8FPzMqo=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=XKsON+hYowGa6zh6kxY6pwS/DV54dh6EFl/ertaUXJddZrkM3wH+OdG0+EwssiNnw +boD/9+lLzJhF7/uwIcKTitMg1wXQb9zdpWSrMvvkrYDz6ZSd+vVjfjb3VkcAcM3Yy 4v7NrRp7C3taRGLpr2e4Hyj7rX6q/m1fguyqyp+aQGq0OLkzeyy8//Mc5CaSHnX8Go KHlOtW+3YXXaBuMDMHhRSNjTd2/WKL7VuonT2nu5rfIxEfg+9dAP+IWIfR1sXmUOZP Pj/alPoSUuC4zL3Bmtl0EtLMhSHFAUrFZFIwqduRcNlD1Er/LIos23UDqqGFYTgAOt WJTzuzR7j4WwQ== Received: from unknown ([IPv6:2601:408:c300:8f09:21e:4fff:fec2:a0f1]) by resomta-ch2-03v.sys.comcast.net with SMTP id ccxTeVWu8fTA8ccxTek9SF; Fri, 19 Jan 2018 20:08:15 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke User-Agent: edbrowse/3.7.1 Date: Fri, 19 Jan 2018 15:08:15 -0500 Message-ID: <20180019150815.eklhad@comcast.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=nextpart-eb-770373 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfN3THIc/xb1+8dlm4CyBE+1dYijvIXhay53/1rSie/2m85mHKmE9HoAoxRPUi9G6PA6ity3l1D00l8ZPrRfQDvgD0oKMzShPA+Hj9u7ybcfe9sJyPWPi vwChd3dySrKmtp+UhAqY+LMUTp4RrC0EW7HEmzsBShEmPhm5C4b/oAhu Subject: [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:08:16 -0000 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --nextpart-eb-770373 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable My note to Sami, and his reply. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D 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. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D 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 =3D x.foobar' and 'v =3D 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 =3D 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 --nextpart-eb-770373--