Error stack

classic Classic list List threaded Threaded
56 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Error stack

Erik Arvidsson
I wrote a new strawman for Error stack which is now available in some
form in all major browser (if betas are considered).

http://wiki.ecmascript.org/doku.php?id=strawman:error_stack

Feedback wanted.

--
erik
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Error stack

John J Barton
On Thu, Jun 7, 2012 at 11:37 AM, Erik Arvidsson
<[hidden email]> wrote:
> I wrote a new strawman for Error stack which is now available in some
> form in all major browser (if betas are considered).
>
> http://wiki.ecmascript.org/doku.php?id=strawman:error_stack
>
> Feedback wanted.

You might look at the Mueller format:
https://gist.github.com/312a55532fac0296f2ab

Note that the V8 stack is not a property of the error object but
rather a getter. This is a valuable performance advantage since the
stack is not converted from C++ array to string until the getter is
called.

Critical for tools is the ability to linkify the stack trace so we
need the grammar to allow the URLs to be unambiguously parsable,
including avoiding content of the error message from interfering.

jjb


>
> --
> erik
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Error stack

Erik Arvidsson
On Thu, Jun 7, 2012 at 12:05 PM, John J Barton
<[hidden email]> wrote:

> On Thu, Jun 7, 2012 at 11:37 AM, Erik Arvidsson
> <[hidden email]> wrote:
>> I wrote a new strawman for Error stack which is now available in some
>> form in all major browser (if betas are considered).
>>
>> http://wiki.ecmascript.org/doku.php?id=strawman:error_stack
>>
>> Feedback wanted.
>
> You might look at the Mueller format:
> https://gist.github.com/312a55532fac0296f2ab
>
> Note that the V8 stack is not a property of the error object but
> rather a getter. This is a valuable performance advantage since the
> stack is not converted from C++ array to string until the getter is
> called.

This is well known. Engines can implement lazy data properties too but
maybe that is too magical. I'm fine speccing this as an accessor but
if it is an accessor we should spec it as on Error.prototype and not
on the instance.

> Critical for tools is the ability to linkify the stack trace so we
> need the grammar to allow the URLs to be unambiguously parsable,
> including avoiding content of the error message from interfering.

Agreed and I believe the V8 format fulfills that requirement.

--
erik
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Error stack

John Lenz-4
It would be great to see this standardized!

On Thu, Jun 7, 2012 at 12:17 PM, Erik Arvidsson <[hidden email]> wrote:
On Thu, Jun 7, 2012 at 12:05 PM, John J Barton
<[hidden email]> wrote:
> On Thu, Jun 7, 2012 at 11:37 AM, Erik Arvidsson
> <[hidden email]> wrote:
>> I wrote a new strawman for Error stack which is now available in some
>> form in all major browser (if betas are considered).
>>
>> http://wiki.ecmascript.org/doku.php?id=strawman:error_stack
>>
>> Feedback wanted.
>
> You might look at the Mueller format:
> https://gist.github.com/312a55532fac0296f2ab
>
> Note that the V8 stack is not a property of the error object but
> rather a getter. This is a valuable performance advantage since the
> stack is not converted from C++ array to string until the getter is
> called.

This is well known. Engines can implement lazy data properties too but
maybe that is too magical. I'm fine speccing this as an accessor but
if it is an accessor we should spec it as on Error.prototype and not
on the instance.

> Critical for tools is the ability to linkify the stack trace so we
> need the grammar to allow the URLs to be unambiguously parsable,
> including avoiding content of the error message from interfering.

Agreed and I believe the V8 format fulfills that requirement.

--
erik
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Error stack

Jason Orendorff
In reply to this post by Erik Arvidsson
On Thu, Jun 7, 2012 at 1:37 PM, Erik Arvidsson <[hidden email]> wrote:
> I wrote a new strawman for Error stack which is now available in some
> form in all major browser (if betas are considered).
>
> http://wiki.ecmascript.org/doku.php?id=strawman:error_stack
>
> Feedback wanted.

This isn't machine parseable in all cases, since the .message may
contain newlines and can end with something like "\n  at ..."

Changing this in Firefox would affect any Firefox addons that use
Error.stack, but maybe we can take that hit.

-j
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Error stack

Erik Arvidsson
On Thu, Jun 7, 2012 at 1:12 PM, Jason Orendorff
<[hidden email]> wrote:
> This isn't machine parseable in all cases, since the .message may
> contain newlines and can end with something like "\n  at ..."

That is a good point. This also applies to the "name" of a function
(and object when included). It is trivial to create a function "name"
that breaks the V8 style formatting. SpiderMonkey "gets" away with
this by using the name of the function expression and it does not try
to deduce a name based on the code..

window['\n@'] = function() {
  alert(new Error().stack);
};

When I first set out to write the proposal I was set on the
SpiderMonkey formatting but as I researched this I drifted closer and
closer to the V8 formatting. The thing that convinced me was eval.

I also don't think that providing ErrorName: ErrorMessage is a hard
requirement. The same information is already available using
errorObject.name and errorObject.message.

If we remove the first line and require that non identifiers are
quoted I think we can guarantee that the value is machine parseable
again.

> Changing this in Firefox would affect any Firefox addons that use
> Error.stack, but maybe we can take that hit.

For web apps we already have to parse two different versions so I'm
not too concerned about that case. The WebKit mobile web does not
depend on either format (Safari doesn't have it in any shipping
version yet) so the two problematic big eco systems are Firefox and
Chrome extensions (and Node.js?)

--
erik
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Error stack

Domenic Denicola-2
Machine-parsability might be reaching too far, especially if you lose the benefits of nice function/method name inference. Instead, perhaps a separate strawman to standardize something like the V8 stack trace API [1]?

It is used in Node for providing long stack traces [2], [3], [4]. It's a bit cumbersome, e.g. maybe a separate error.stackFrames getter would be nicer and the Java-style getFileName() methods could become simple properties. But the fact that it exists is extremely useful.

[1]: http://code.google.com/p/v8/wiki/JavaScriptStackTraceApi
[2]: https://github.com/tlrobinson/long-stack-traces
[3]: https://github.com/kriskowal/q/blob/0c1ffdc50bbbba6ea77c3e97075fab35ab9f7b2d/q.js#L261-405, https://github.com/kriskowal/q/blob/0c1ffdc50bbbba6ea77c3e97075fab35ab9f7b2d/q.js#L1307-1321
[4]: https://github.com/NobleJS/WinningJS-todo/commit/2d4ca10c4f672dac9f021b697c4c72bbff321ed9

________________________________________
From: [hidden email] [[hidden email]] on behalf of Erik Arvidsson [[hidden email]]
Sent: Thursday, June 07, 2012 16:39
To: Jason Orendorff
Cc: [hidden email]
Subject: Re: Error stack

On Thu, Jun 7, 2012 at 1:12 PM, Jason Orendorff
<[hidden email]> wrote:
> This isn't machine parseable in all cases, since the .message may
> contain newlines and can end with something like "\n  at ..."

That is a good point. This also applies to the "name" of a function
(and object when included). It is trivial to create a function "name"
that breaks the V8 style formatting. SpiderMonkey "gets" away with
this by using the name of the function expression and it does not try
to deduce a name based on the code..

window['\n@'] = function() {
  alert(new Error().stack);
};

When I first set out to write the proposal I was set on the
SpiderMonkey formatting but as I researched this I drifted closer and
closer to the V8 formatting. The thing that convinced me was eval.

I also don't think that providing ErrorName: ErrorMessage is a hard
requirement. The same information is already available using
errorObject.name and errorObject.message.

If we remove the first line and require that non identifiers are
quoted I think we can guarantee that the value is machine parseable
again.

> Changing this in Firefox would affect any Firefox addons that use
> Error.stack, but maybe we can take that hit.

For web apps we already have to parse two different versions so I'm
not too concerned about that case. The WebKit mobile web does not
depend on either format (Safari doesn't have it in any shipping
version yet) so the two problematic big eco systems are Firefox and
Chrome extensions (and Node.js?)

--
erik
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Error stack

Charles Kendrick-2
In reply to this post by Erik Arvidsson
Thanks for taking this on Erik.

I would suggest the following, which is mostly based on the
information it was possible to extract from IE6 (which is amazingly
still the leader in programmatic access to error information) as well
as information we were able to get by writing a Firefox extension.

All of the following might be optionally enabled, similar to
Error.stackTraceLimit, if you think it's too verbose.

1. show the parameter values

.. and do so intelligently:

a. Show Arrays with length: Array[5]

b. truncate long strings and show length: "the quick brown fox jumped ..."[45]

c. format dates compactly: Date(2012/5/2 5:00)

d. for Objects, use the toString() method if it's been customized on
the object, and for other objects instead of [Object object] pick
salient properties such as ID/id, name, title, type, or label.

For example, in our traces we would show Obj{title:"foo"} if an Object
with no customized toString() were present as a parameter and it
happened to have a "title" property.

This is a general strategy for dumping the value of something shown in
a stack trace and is assumed for other features below.


2. show the value of "this" if it's not the window

This is extremely important in OO frameworks.  It tells you exactly
what instances are involved in the call stack.  Traces that go through
recursive algorithms can be almost useless without this.

For example:

ReferenceError: doSomething is not defined
    at f (http://www.example.com/temp.html:5:5) [on Obj{ID:"foo"}]
    at g (eval at h (http://www.example.com/temp.html:6:5))
    at http://www.example.com/temp.html:11:1


3. optionally show the line of code that crashed

ReferenceError: doSomething is not defined
        code: this.doSomething()
    at f (http://www.example.com/temp.html:5:5)
    at g (eval at h (http://www.example.com/temp.html:6:5))
    at http://www.example.com/temp.html:11:1


3. optionally show the line of code that calls down to the next frame

ReferenceError: doSomething is not defined
        code: this.doSomething()
    at f (http://www.example.com/temp.html:5:5)
        code: if (something) f();
    at g (eval at h (http://www.example.com/temp.html:6:5))
        code: g(currentValue);
    at http://www.example.com/temp.html:11:1


4. optionally dump all non-parameter local variables for the crashing frame

ReferenceError: doSomething is not defined
        code: this.doSomething()
        vars:
            value: 5
            parent: Obj{name:"foo"}
    at f (http://www.example.com/temp.html:5:5) [on: Obj{ID:1}]
        code: if (something) f();

----

A couple quick notes: some might argue this is pushing stacks to do
things debuggers do.  But, you don't have a debugger when you are
trying to solve a problem in a live application, and you don't have a
debugger when a customer is sending you logs and you can't even access
the application.

But with stack traces like the above, especially when combined with
good logging, you can be almost psychic when analyzing issues.

This information is very easy for the browser implementer to retrieve
so I don't think it imposes an undue burden, and from my 13 years of
experience helping customers with issues in a large JavaScript
framework, I can tell you that the value is difficult to overstate.

On Thu, Jun 7, 2012 at 11:37 AM, Erik Arvidsson
<[hidden email]> wrote:

> I wrote a new strawman for Error stack which is now available in some
> form in all major browser (if betas are considered).
>
> http://wiki.ecmascript.org/doku.php?id=strawman:error_stack
>
> Feedback wanted.
>
> --
> erik
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Error stack

Charles Kendrick-2
In reply to this post by Domenic Denicola-2
I agree that something like error.stackFrames would be ideal.  However
I would say the V8 stack trace API is missing 3 key things:

1. access to parameter values
2. access to local variables defined in the function
3. access to the line of code that crashed / called the next frame
without having to go download the source file and use the line number
to find it.  This is even more important for generated / eval()'d code
where there is no source file per se.

Note that access to the function for the frame via getFunction() is
inadequate - doesn't work with recursion.  APIs to get local variables
and parameter values would need to be on the stackFrame.

P.S. fascinating to learn that Node.js does long traces, we have done
the same in SmartClient for a long time.

On Thu, Jun 7, 2012 at 2:47 PM, Domenic Denicola
<[hidden email]> wrote:

> Machine-parsability might be reaching too far, especially if you lose the benefits of nice function/method name inference. Instead, perhaps a separate strawman to standardize something like the V8 stack trace API [1]?
>
> It is used in Node for providing long stack traces [2], [3], [4]. It's a bit cumbersome, e.g. maybe a separate error.stackFrames getter would be nicer and the Java-style getFileName() methods could become simple properties. But the fact that it exists is extremely useful.
>
> [1]: http://code.google.com/p/v8/wiki/JavaScriptStackTraceApi
> [2]: https://github.com/tlrobinson/long-stack-traces
> [3]: https://github.com/kriskowal/q/blob/0c1ffdc50bbbba6ea77c3e97075fab35ab9f7b2d/q.js#L261-405, https://github.com/kriskowal/q/blob/0c1ffdc50bbbba6ea77c3e97075fab35ab9f7b2d/q.js#L1307-1321
> [4]: https://github.com/NobleJS/WinningJS-todo/commit/2d4ca10c4f672dac9f021b697c4c72bbff321ed9
>
> ________________________________________
> From: [hidden email] [[hidden email]] on behalf of Erik Arvidsson [[hidden email]]
> Sent: Thursday, June 07, 2012 16:39
> To: Jason Orendorff
> Cc: [hidden email]
> Subject: Re: Error stack
>
> On Thu, Jun 7, 2012 at 1:12 PM, Jason Orendorff
> <[hidden email]> wrote:
>> This isn't machine parseable in all cases, since the .message may
>> contain newlines and can end with something like "\n  at ..."
>
> That is a good point. This also applies to the "name" of a function
> (and object when included). It is trivial to create a function "name"
> that breaks the V8 style formatting. SpiderMonkey "gets" away with
> this by using the name of the function expression and it does not try
> to deduce a name based on the code..
>
> window['\n@'] = function() {
>  alert(new Error().stack);
> };
>
> When I first set out to write the proposal I was set on the
> SpiderMonkey formatting but as I researched this I drifted closer and
> closer to the V8 formatting. The thing that convinced me was eval.
>
> I also don't think that providing ErrorName: ErrorMessage is a hard
> requirement. The same information is already available using
> errorObject.name and errorObject.message.
>
> If we remove the first line and require that non identifiers are
> quoted I think we can guarantee that the value is machine parseable
> again.
>
>> Changing this in Firefox would affect any Firefox addons that use
>> Error.stack, but maybe we can take that hit.
>
> For web apps we already have to parse two different versions so I'm
> not too concerned about that case. The WebKit mobile web does not
> depend on either format (Safari doesn't have it in any shipping
> version yet) so the two problematic big eco systems are Firefox and
> Chrome extensions (and Node.js?)
>
> --
> erik
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Error stack

Dave Herman
In reply to this post by Erik Arvidsson
> I wrote a new strawman for Error stack which is now available in some
> form in all major browser (if betas are considered).

Thanks for writing this up. I left a couple comments on the strawman, but I should just respond here.

- I'm in favor of trying to come up with a common format as much as possible, so that programs that manipulate stack traces can be written once and don't have to build compatibility layers like http://stacktracejs.com.

- But we should be careful not to overspecify in ways that constrain optimizations. Despite the fact that we usually err on the side of full specification, this is actually one place where I think we can and should avoid it. The Chrome stackTraceLimit idea is interesting, but does V8 actually promise never to inline within the most recent n frames?

- You mentioned that compatibility requires error.stack to be a string, even though programs would really like to have a structured version. Should we offer a different property with structured stack frame info (probably with a getter to allow straight-forward lazy construction), called error.stackFrames or error.stackEntries or something?

Thanks,
Dave

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Error stack

T.J. Crowder
On 8 June 2012 04:28, David Herman <[hidden email]> wrote:
- You mentioned that compatibility requires error.stack to be a string, even though programs would really like to have a structured version. Should we offer a different property with structured stack frame info (probably with a getter to allow straight-forward lazy construction), called error.stackFrames or error.stackEntries or something?

Big +1 on that. Avoiding parsing information the engine has as discrete items already is a Good Thing(tm). Perhaps it'll be aspirational at first, but if specified now it'll happen eventually.

-- T.J.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Error stack

Wes Garland
error.stackFrames, an Array which contains one object per stack frame, describing function name (if any), filename, line number, some kind of instance Id (for closures), arguments, and closed-over variables.... would be absolutely incredible from my POV.

Tie it up in a nice package that can be JSON.stringified, and that SSJS back-ends can send better debug info back to the browser for the developers to consume.

Wes

On 8 June 2012 02:57, T.J. Crowder <[hidden email]> wrote:
On 8 June 2012 04:28, David Herman <[hidden email]> wrote:
- You mentioned that compatibility requires error.stack to be a string, even though programs would really like to have a structured version. Should we offer a different property with structured stack frame info (probably with a getter to allow straight-forward lazy construction), called error.stackFrames or error.stackEntries or something?

Big +1 on that. Avoiding parsing information the engine has as discrete items already is a Good Thing(tm). Perhaps it'll be aspirational at first, but if specified now it'll happen eventually.

-- T.J.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Error stack

Erik Arvidsson
In reply to this post by Charles Kendrick-2
On Thu, Jun 7, 2012 at 3:21 PM, Charles Kendrick <[hidden email]> wrote:
> I agree that something like error.stackFrames would be ideal.  However
> I would say the V8 stack trace API is missing 3 key things:
>
> 1. access to parameter values
> 2. access to local variables defined in the function
> 3. access to the line of code that crashed / called the next frame

One thing that might not have been as clear as I wanted is that this
is trying to spec Error stack as it exists today. This is not intended
to cover any kind of debugging APIs. That is a completely different
topic and has a lot of security implications.

--
erik
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Error stack

Erik Arvidsson
In reply to this post by T.J. Crowder
On Thu, Jun 7, 2012 at 11:57 PM, T.J. Crowder <[hidden email]> wrote:

> On 8 June 2012 04:28, David Herman <[hidden email]> wrote:
>>
>> - You mentioned that compatibility requires error.stack to be a string,
>> even though programs would really like to have a structured version. Should
>> we offer a different property with structured stack frame info (probably
>> with a getter to allow straight-forward lazy construction), called
>> error.stackFrames or error.stackEntries or something?
>
>
> Big +1 on that. Avoiding parsing information the engine has as discrete
> items already is a Good Thing(tm). Perhaps it'll be aspirational at first,
> but if specified now it'll happen eventually.

There has been some interest in trying to align the existing Error
stack property and this proposal is about that.

Could we provide a new better alternative API? Of course. Feel free to
come up with another proposal.

--
erik
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Error stack

Alex Vincent
In reply to this post by Erik Arvidsson

---------- Forwarded message ----------
From: Erik Arvidsson <[hidden email]>
To: [hidden email]
Cc: 
Date: Thu, 7 Jun 2012 11:37:41 -0700
Subject: Error stack
I wrote a new strawman for Error stack which is now available in some
form in all major browser (if betas are considered).

http://wiki.ecmascript.org/doku.php?id=strawman:error_stack

Feedback wanted.

As the person who originally proposed the stack property to Mozilla over ten years ago, I am absolutely thrilled to see this as a strawman on Harmony.  In any form. 

For reference, the original bug is at https://bugzilla.mozilla.org/show_bug.cgi?id=123177 .

The only thing I might ask is to keep the ability to alter the stack - in a controlled way.  Specifically, I've had occasion to want to remove the first two or three frames of an error stack, because I was implementing an assert() function.  When the assert failed, I wanted the stack to start at the actual line of the assert call, instead of a couple of lines away (new Error(), then the assert function, and then the caller of assert).  That said, I'd understand if the Harmony working group rejected this and required the property be read-only and never changeable.

Alex Vincent
--
"The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Error stack

Charles Kendrick-2
In reply to this post by Charles Kendrick-2
On Fri, Jun 8, 2012 at 5:38 AM, Patrick Mueller <[hidden email]> wrote:
> Personally, I'm happy with a user-land way of being able to generate
> something like this, in V8:
>
>     https://gist.github.com/312a55532fac0296f2ab

You can actually do this now in userland in Chrome (except the
CoffeeScript aspect).  This link was posted yesterday:

     http://code.google.com/p/v8/wiki/JavaScriptStackTraceApi

.. but I've subsequently commented on the page with some working code
since people were having trouble understanding how to get to the array
of CallSite objects (it's a pretty bizarre API).

> If there's issues dealing with recursion, or whatever, fine, just tell me
> what they are.

You can't get to function arguments for recursive functions (appears
more than once on stack).  I filed this bug on it, perhaps you'd like
to "star" it:

    http://code.google.com/p/v8/issues/detail?id=2169

Note: Erik just mentioned in passing that debugging APIs have security
implications - this is potentially true for local variable access, but
JavaScript VMs already have to handle correct security for access to
function arguments due to the existing  function.arguments API.  So
nothing new there in terms of risk or burden on the browser
implementer.

> I think that getting access to parm values/locals is interesting, but
> veering into the "land of the debugger".

Just to connect the dots, as I said previously, you don't have a
debugger when you are looking at logs for an application you can't
access.  Programmatic access to this information is critical in that
use case, but also extremely valuable just everyday - how many times
have you seen an application get into an error state that you aren't
sure how to reproduce, when you didn't happen to be in the debugger?
If you had robust stack traces you'd have a lot more to go on.

With IE6 we solved dozens of bugs just from stack trace information.
Ah the good old days!  (yes that's sarcasm + irony)

> I'd prefer a clean take on
> "debugging APIs" rather than evolve it from an exception back-trace use
> case.  When do we start talking about that?  I'm looking at you,
> --expose_debug_as (V8 option).

An Array of StackFrame / CallSite objects is pretty much a clean
debugging API and not really something grafted on.  The same concept
appears in most debug APIs, eg Java's:

    http://docs.oracle.com/javase/1.4.2/docs/guide/jpda/jdi/com/sun/jdi/StackFrame.html

> --
> Patrick Mueller
> http://muellerware.org
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Error stack

Brandon Benvie
You can get the arguments. Here's an example of getting more info out of a try..catch: https://gist.github.com/2898384

Which results in error.stack being an array of objects like (function, arguments, and receiver are actual function/array/object)

{
  function: <function>,
  name: "InjectedScript._evaluateOn",
  inferredName: "_evaluateOn",
  arguments: <Array[5]>,
  invocationType: "call",
  receiver: <receiver>,
  inferredType: "Object",
  origin: undefined,
  column: 33,
  line: 343,
  position: 12853,
  type: "file"
};

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Error stack

Erik Arvidsson
On Fri, Jun 8, 2012 at 3:25 PM, Brandon Benvie
<[hidden email]> wrote:

> You can get the arguments. Here's an example of getting more info out of a
> try..catch: https://gist.github.com/2898384
>
> Which results in error.stack being an array of objects like (function,
> arguments, and receiver are actual function/array/object)
>
> {
>   function: <function>,
>   name: "InjectedScript._evaluateOn",
>   inferredName: "_evaluateOn",
>   arguments: <Array[5]>,
>   invocationType: "call",
>   receiver: <receiver>,
>   inferredType: "Object",
>   origin: undefined,
>   column: 33,
>   line: 343,
>   position: 12853,
>   type: "file"
> };

Once again, exposing the actual arguments, receiver and function
object references is a security issue and completely out of scope for
this. This is not related to cross domain access but related to object
capabilities.

Here is an example of when this would be a security issue:

function foo(secret) {
  'use strict';
  thirdPartyFunction();
}

...

function thirdPartyFunction() {
  getStackTrace(new Error)[1].arguments[0]; // oops I just leaked the secret.
}

Any proposal that exposes argument values and/or object references are
dead on arrival.

--
erik
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Error stack

Wes Garland
It might be out of scope, but as a developer, I would almost give my left nut to have the kind of information in Brendan's example.

Even more so if it the browser guys made it available as an argument to the window.onerror callback.

Wes

--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Error stack

Charles Kendrick-2
In reply to this post by Erik Arvidsson
> Once again, exposing the actual arguments, receiver and function
> object references is a security issue and completely out of scope for
> this. This is not related to cross domain access but related to object
> capabilities.

Erik how do you reconcile this with the fact that this information can
already be obtained in most production browsers via stack walking?

Also, forgive my ignorance, but is it an explicit goal of the
JavaScript language that two scripts in a web page from the same
domain must not be able to discover each other's runtime arguments?

On Fri, Jun 8, 2012 at 3:50 PM, Erik Arvidsson <[hidden email]> wrote:

> On Fri, Jun 8, 2012 at 3:25 PM, Brandon Benvie
> <[hidden email]> wrote:
>> You can get the arguments. Here's an example of getting more info out of a
>> try..catch: https://gist.github.com/2898384
>>
>> Which results in error.stack being an array of objects like (function,
>> arguments, and receiver are actual function/array/object)
>>
>> {
>>   function: <function>,
>>   name: "InjectedScript._evaluateOn",
>>   inferredName: "_evaluateOn",
>>   arguments: <Array[5]>,
>>   invocationType: "call",
>>   receiver: <receiver>,
>>   inferredType: "Object",
>>   origin: undefined,
>>   column: 33,
>>   line: 343,
>>   position: 12853,
>>   type: "file"
>> };
>
> Once again, exposing the actual arguments, receiver and function
> object references is a security issue and completely out of scope for
> this. This is not related to cross domain access but related to object
> capabilities.
>
> Here is an example of when this would be a security issue:
>
> function foo(secret) {
>  'use strict';
>  thirdPartyFunction();
> }
>
> ...
>
> function thirdPartyFunction() {
>  getStackTrace(new Error)[1].arguments[0]; // oops I just leaked the secret.
> }
>
> Any proposal that exposes argument values and/or object references are
> dead on arrival.
>
> --
> erik
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
123