[Webkit-unassigned] [Bug 13646] implement Error.prototype.stack
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Mon Aug 20 13:27:18 PDT 2007
http://bugs.webkit.org/show_bug.cgi?id=13646
------- Comment #4 from dhtmlkitchen at gmail.com 2007-08-20 13:27 PDT -------
(In reply to comment #3)
> The "stack" property in Firefox (do note the lack of caps on the second "f",
> Garrett) is not on Error.prototype -- it's a per-instance property computed
> when the exception is created (I think).
Is a null-valued property is better or worse design than an undefined value (or
dynamically added property)?
> Do also note this most likely degrades exception-throwing performance, unless
> you garbage-collect stack frames or something like it (not likely in the
> presence of native stack frames, and not otherwise useful in JS as defined by
> the standard and by the Real World).
Some people find e.stack useful when debugging others' code -- I know I have,
and at work, too! (not academic discussion at MIT)
It's possible to create a findStack( error ) function to crawl up the function
caller chain. But this code is ideally not deployed in a "real world" app. So
what happens when deployed code has a bug.
When there's a P1 bug to fix, or if the developer gets called back into work on
a Fri night (tired), it's nice to find the error right away. Do I really need
to explain why a stack trace is useful?
What is your useful, real world solution to obtaining a stack trace, Jeff?
--
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
More information about the webkit-unassigned
mailing list