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
<erik.arvids...@gmail.com> 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
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
