Re: Error stack strawman

On Thu, Feb 25, 2016 at 6:45 PM, Gary Guo wrote: > Things became more complicated when considering async & generators. For > async calls as mentioned before somewhere in the thread, only Firefox > Nightly build includes histories of the frame, while all other browsers > don't. It could be useful

RE: Error stack strawman

Things became more complicated when considering async & generators. For async calls as mentioned before somewhere in the thread, only Firefox Nightly build includes histories of the frame, while all other browsers don't. It could be useful to include that in stack trace, but it will then be a s

Re: Error stack strawman

On 2/24/16 6:59 PM, Steve Fink wrote: (Or at least, that's my understanding of what is going on. I'm not sure if that stuff is used for Error.stack yet.) It is. See https://bugzilla.mozilla.org/show_bug.cgi?id=1038238 -Boris ___ es-discuss mailing l

Re: Error stack strawman

On 02/24/2016 01:30 PM, Mark S. Miller wrote: [2] This solves only one of the cross-realm issue with stacks. It does nothing to address worries about cross-realm stacks. We do have code in FF that handles cross-realm stacks, or at least a close moral equivalent to them. The stacks are stored

Re: Error stack strawman

On Wed, Feb 24, 2016 at 2:37 PM, Boris Zbarsky wrote: > On 2/24/16 5:35 PM, Boris Zbarsky wrote: > >> Clearly this Just >> Works with a value property, across all browsers at that point, so we >> made it work with the accessor too. >> > > Oh, and we made it work the way [Replaceable] stuff on win

Re: Error stack strawman

On 2/24/16 5:35 PM, Boris Zbarsky wrote: Clearly this Just Works with a value property, across all browsers at that point, so we made it work with the accessor too. Oh, and we made it work the way [Replaceable] stuff on window works: the setter defines a value property on the object which ther

Re: Error stack strawman

On 2/24/16 4:30 PM, Mark S. Miller wrote: [1] For some reason the FF stack accessor has both getter and setter. I don't see any reason for a setter. We ran into code "in the wild" (more precisely, within our own test suite infrastructure, but we have no reason to believe this would not happen

Re: Error stack strawman

Huh, weird. From the discussions that led to < https://github.com/claudepache/es-regexp-legacy-static-properties> being proposed and the discussion on that issue, for me to take a consistent position, I must sadly concede the following: We allowed a grossly leaky api (the RegExp statics, which lea

Re: Error stack strawman

On Wed, Feb 24, 2016 at 11:40 AM, Steve Fink wrote: > On 02/19/2016 01:26 AM, Andreas Rossberg wrote: > > On 19 February 2016 at 03:13, Gary Guo wrote: > > If we are not going to indicate tail call some way, debugging might be >> extremely difficult, and the stack result might be making no sense

Re: Error stack strawman

On 02/19/2016 01:26 AM, Andreas Rossberg wrote: On 19 February 2016 at 03:13, Gary Guo > wrote: If we are not going to indicate tail call some way, debugging might be extremely difficult, and the stack result might be making no sense at all. A tail call

Re: Error stack strawman

On 24 February 2016 at 02:01, John Lenz wrote: > To be clear I meant, the VM knows *statically* whether to write code for a > regular call or a tail call and that it is *possible* to do something > *clever* by inspecting and rewriting the stack. Specifically, if you can > inspect the stack for s

Re: Error stack strawman

To be clear I meant, the VM knows *statically* whether to write code for a regular call or a tail call and that it is *possible* to do something *clever* by inspecting and rewriting the stack. Specifically, if you can inspect the stack for something that is inserted before performing the first tai

Re: Error stack strawman

Would it be possible to just define functions with an offset of exactly N bits before, with tail calls having a separate entry point than regular calls? Tail calls are already determined statically by spec, so you could add/subtract N bits to the code you generate for a function call in optimized c

Re: Error stack strawman

On 19 February 2016 at 10:29, Andreas Rossberg wrote: > On 19 February 2016 at 06:29, John Lenz wrote: > >> However, at the CPU level, it seems like you would be better pushing an >> return address for a special function that indicated the start of a >> sequence of tail calls. That way you trad

Re: Error stack strawman

On 19 February 2016 at 06:29, John Lenz wrote: > However, at the CPU level, it seems like you would be better pushing an > return address for a special function that indicated the start of a > sequence of tail calls. That way you trade only some > complexity/performance for tail calls (an inspec

Re: Error stack strawman

On 19 February 2016 at 03:13, Gary Guo wrote: > Andreas wrote: > > This would be fairly difficult to support by implementations. In V8, for > example, we currently have no way of reconstructing that information, nor > would it be easy or cheap to add that. A frame is created by the callee, > but

Re: Error stack strawman

On Thu, Feb 18, 2016 at 6:13 PM, Gary Guo wrote: > Andreas wrote: > > This would be fairly difficult to support by implementations. In V8, for > example, we currently have no way of reconstructing that information, nor > would it be easy or cheap to add that. A frame is created by the callee, >

Re: Error stack strawman

On Thu, Feb 18, 2016 at 6:13 PM, Gary Guo wrote: > Andreas wrote: > > This would be fairly difficult to support by implementations. In V8, for > example, we currently have no way of reconstructing that information, nor > would it be easy or cheap to add that. A frame is created by the callee, >

RE: Error stack strawman

Andreas wrote:> This would be fairly difficult to support by implementations. In V8, for example, we currently have no way of reconstructing that information, nor would it be easy or cheap to add that. A frame is created by the callee, but that does not know how it got called. Funnelling throu

Re: Error stack strawman

On 18 February 2016 at 02:36, Gary Guo wrote: > * isTail will be set when the frame indicates a frame created by tail call > instead of normal function call. Caller's frame is already removed so we > need some indication for that to help debugging. > This would be fairly difficult to support by

Re: Error stack strawman

Mark Knichel has a lot of information regarding stacks and error handling in various browsers here: https://github.com/mknichel/javascript-errors On Wed, Feb 17, 2016 at 4:19 PM, Gary Guo wrote: > The strawman looks very old, so I've created a new one. > > Repo: https://github.com/nbdd0121/es-e

Re: Error stack strawman

l ;) > > Gary Guo > > -- > Date: Wed, 17 Feb 2016 17:04:39 -0800 > Subject: Re: Error stack strawman > From: erig...@google.com > To: nbdd0...@hotmail.com > CC: es-discuss@mozilla.org > > > > > On Wed, Feb 17, 2016 at 4:19 PM,

RE: Error stack strawman

e the function object from the frame? * I wonder if putting special cases in (), such as (native) will cause any problem. No one will have a file called "(native)" in reality, isn't it? Gary Guo Date: Wed, 17 Feb 2016 17:04:39 -0800 Subject: Re: Error stack strawman From: erig...@

Re: Error stack strawman

On Wed, Feb 17, 2016 at 4:19 PM, Gary Guo wrote: > The strawman looks very old, so I've created a new one. > > Repo: https://github.com/nbdd0121/es-error-stack > > I've collected many information about current implementation from IE, > Edge, Chrome and Firefox, but missing Safari's. Many thanks i

RE: Error stack strawman

The strawman looks very old, so I've created a new one. Repo: https://github.com/nbdd0121/es-error-stack I've collected many information about current implementation from IE, Edge, Chrome and Firefox, but missing Safari's. Many thanks if some one can collect these info and create a pull reques

Re: Error stack strawman

[+es-discuss] resending with es-discuss included. On Tue, Feb 9, 2016 at 9:48 PM, Terry Stanley wrote: > Hi Boris, > > I've recently made changes to Causeway that I think you'll be interested > in. The (revived) Stack Explorer view will give you a hands-on sense of our > support of async stacks

Re: Error stack strawman

On 2/10/16 9:47 PM, Jonathan Kingston wrote: Could the trace output just finish early at these origin boundaries The problem is that some browsers don't have origin boundaries at all in places where others do. -Boris ___ es-discuss mailing list es-

Re: Error stack strawman

Yeah interop issues of the output. (Sorry I'm not being clear) It seems the interop has been the main reason this has stalled as a proposal all these years. Could the trace output just finish early at these origin boundaries perhaps rather than try and implement cross browser? With the right API t

Re: Error stack strawman

On 2/10/16 7:12 PM, Jonathan Kingston wrote: Is implementing stack traces cross browser mostly difficult because of the use of document.domain or are there other issues blocking? Ah, you mean in terms of interop? I expect document.domain and built-ins to be the main thing that browsers will e

Re: Error stack strawman

Is implementing stack traces cross browser mostly difficult because of the use of document.domain or are there other issues blocking? On Wed, Feb 10, 2016 at 3:03 PM Boris Zbarsky wrote: > On 2/10/16 4:52 AM, Jonathan Kingston wrote: > > @Boris does the main difficulties hinge on document.domain

Re: Error stack strawman

On 2/10/16 4:52 AM, Jonathan Kingston wrote: @Boris does the main difficulties hinge on document.domain? Main difficulties with what? -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

Just want to keep this going as I think mostly people agree it is worthy as an addition just the details are difficult etc. @Boris does the main difficulties hinge on document.domain? There are discussions again in WebAppSec to deprecate that so perhaps the trace could also not work if document.do

RE: Error stack strawman

One thing needs to be considered as well. What should be displayed for tail calls?___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

On 1/25/16 1:55 PM, Gary Guo wrote: I believe a lot of additional work needs to be done for this proposal to make it works across realm. Consider the invocation chain: alpha, alpha0 (in realm A) beta, beta0 (in realm B) alpha -> alpha0 -> beta -> beta0 -> alpha ->alpha0 -> beta -> beta0 -> throw

RE: Error stack strawman

I believe a lot of additional work needs to be done for this proposal to make it works across realm. Consider the invocation chain:alpha, alpha0 (in realm A)beta, beta0 (in realm B)alpha -> alpha0 -> beta -> beta0 -> alpha ->alpha0 -> beta -> beta0 -> throws Here comes the question. What should

Re: Error stack strawman

On 1/22/16 4:51 PM, Terry Stanley wrote: Breaking on console.log: FF debugger showed single turn call stack Chrome debugger with Async selected showed deep stack Console output: FF showed deep stack (as expected) Chrome showed single turn Seems like people are incrementally introduc

Re: Error stack strawman

On 1/20/16 10:10 AM, Mark S. Miller wrote: I think the useful thing to do is to standardize the extended Causeway stack trace format: This format doesn't have an obvious way to represent "async stacks" [1], short of hacks with the "functionName" or the "source", right? Gecko right now repres

Re: Error stack strawman

On Tue, Jan 19, 2016 at 6:35 PM, Jonathan Kingston wrote: > Hi Mark, > > Sorry for the delay, thank you for that response it was very useful. > > Do you think it would make sense to open an API for Error stack that would > be purely based upon user agent implementation? I'm not familiar with the

Re: Error stack strawman

Hi Mark, Sorry for the delay, thank you for that response it was very useful. Do you think it would make sense to open an API for Error stack that would be purely based upon user agent implementation? I'm not familiar with the internals of the traces but I have seen comments mentioning performanc

Re: Error stack strawman

On Mon, Jan 11, 2016 at 10:05 PM, Mark S. Miller wrote: > I am very interested. See the extended Causeway stack format in > https://github.com/google/caja/blob/master/src/com/google/caja/ses/debug.js > >From that page, the JSON Schema-ish in an ad-hoc notation: stacktrace ::= {calls: [frame*]}

Re: Error stack

On Tue, Jun 12, 2012 at 5:19 AM, Mark S. Miller wrote: > On Tue, Jun 12, 2012 at 10:14 AM, Charles Kendrick > wrote: >> The only way I can see this working is if there is a way for a given >> piece of code to trap an error and ask some kind of (elevated >> privilege) logging system to provide dia

Re: Error stack

Mark S. Miller wrote: I'm not yet arguing that or the opposite, rather, I'm confused about what "non-strict-only" means in this context. Actual stacks consist of a mixture of strict and non-strict activations. This isn't so in personal projects or even all-homegrown products or shared projects

Re: Error stack

On 12 June 2012 01:36, Charles Kendrick wrote: >> Your point about not violating "use strict" or elaborating too much is good, >> but I want to push back on one thing: local vars may be a bridge too far, >> especially with optimizing JITs, block-scoped let bindings, etc. Making >> arguments availa

Re: Error stack

On Tue, Jun 12, 2012 at 10:14 AM, Charles Kendrick wrote: > On Mon, Jun 11, 2012 at 5:55 PM, Mark S. Miller wrote: >> On Tue, Jun 12, 2012 at 7:59 AM, Charles Kendrick >> wrote: >>> I'm reading this as saying that stack traces in general should not be >>> available unless the code is privileged

Re: Error stack

On Tue, Jun 12, 2012 at 9:17 AM, Brendan Eich wrote: > Mark S. Miller wrote: >> >> On Tue, Jun 12, 2012 at 7:38 AM, Brendan Eich  wrote: >>> >>> Also, as you pointed out, even error.stack leaks information. Where do >>> you >>> draw the line? >> >> >> Conservatively. I suggest that there be no err

Re: Error stack

2012/6/12 Brendan Eich > I see -- thanks. We should try to detail the privileged APIs and their > module(s) a bit more. I used "@reflect" above but I didn't mean to equate > it to Tom's Reflect.* used in conjunction with direct proxies. And not all > reflection facilities are privileged -- more t

Re: Error stack

On Mon, Jun 11, 2012 at 5:55 PM, Mark S. Miller wrote: > On Tue, Jun 12, 2012 at 7:59 AM, Charles Kendrick > wrote: >> I'm reading this as saying that stack traces in general should not be >> available unless the code is privileged in some way.  This can't be >> what you mean, so could you clarif

Re: Error stack

Mark S. Miller wrote: On Tue, Jun 12, 2012 at 7:38 AM, Brendan Eich wrote: Also, as you pointed out, even error.stack leaks information. Where do you draw the line? Conservatively. I suggest that there be no error.stack, but rather getStack(error), in order to avoid this information leak. W

Re: Error stack

On Tue, Jun 12, 2012 at 7:59 AM, Charles Kendrick wrote: > I'm reading this as saying that stack traces in general should not be > available unless the code is privileged in some way.  This can't be > what you mean, so could you clarify? That is exactly what I mean. --     Cheers,     --MarkM

Re: Error stack

On Mon, Jun 11, 2012 at 4:12 PM, Brendan Eich wrote: > I have a sinking feeling it may be better to do just error.stackFrames, the > new object/number/string lazy stack-trace reflection. We can model it on the > union of error.stack implementations in the field, so those could be > reimplemented u

Re: Error stack

On Mon, Jun 11, 2012 at 4:51 PM, Mark S. Miller wrote: > On Tue, Jun 12, 2012 at 7:38 AM, Brendan Eich wrote: >> I think Charles was arguing that anyone keeping secrets would need "use >> strict" to protect those secrets anyway, because otherwise >> arguments.caller.arguments[i] (given non-strict

Re: Error stack

On Tue, Jun 12, 2012 at 7:38 AM, Brendan Eich wrote: > Also, as you pointed out, even error.stack leaks information. Where do you > draw the line? Conservatively. I suggest that there be no error.stack, but rather getStack(error), in order to avoid this information leak. > I think Charles was a

Re: Error stack

Mark S. Miller wrote: On Tue, Jun 12, 2012 at 7:12 AM, Brendan Eich wrote: Your point about not violating "use strict" or elaborating too much is good, but I want to push back on one thing: local vars may be a bridge too far, especially with optimizing JITs, block-scoped let bindings, etc. Maki

Re: Error stack

> Your point about not violating "use strict" or elaborating too much is good, > but I want to push back on one thing: local vars may be a bridge too far, > especially with optimizing JITs, block-scoped let bindings, etc. Making > arguments available is easier. I definitely recognize that making l

Re: Error stack

On Tue, Jun 12, 2012 at 7:12 AM, Brendan Eich wrote: > Your point about not violating "use strict" or elaborating too much is good, > but I want to push back on one thing: local vars may be a bridge too far, > especially with optimizing JITs, block-scoped let bindings, etc. Making > arguments avai

Re: Error stack

I have a sinking feeling it may be better to do just error.stackFrames, the new object/number/string lazy stack-trace reflection. We can model it on the union of error.stack implementations in the field, so those could be reimplemented under/on-top-of error.stackFrames. But we'll have no compat

Re: Error stack

> It seems to me we've lost the thread (maybe you haven't, but I have -- > apologies for revisiting). In a nutshell, I'm looking for access to function arguments, the receiver, and ideally even local variable values via *some* runtime diagnostic API. These could be all be exposed in an error.stac

Re: Error stack

Charles Kendrick wrote: On Sat, Jun 9, 2012 at 12:26 PM, Brendan Eich wrote: We do not want a non-debugger API that works only some of the time. What we want (IMO) is an API that allows runtime diagnostics to be collected. By necessity, function arguments would be unavailable for some stack

Re: Error stack

On Sat, Jun 9, 2012 at 12:26 PM, Brendan Eich wrote: > We do not want a > non-debugger API that works only some of the time. What we want (IMO) is an API that allows runtime diagnostics to be collected. By necessity, function arguments would be unavailable for some stack frames. This is not a n

Re: Error stack

> Oliver Hunt wrote: >> [...] If you used JSON [...] On Mon, Jun 11, 2012 at 6:35 AM, Brendan Eich wrote: > The easy way out is Error.prototype.stackTrace, a getter that exposes, > deeply and lazily, objects with string and number valued properties cleanly > reflecting the desired information --

Re: Error stack

On 10/06/12 23:57, John Tamplin wrote: On Sun, Jun 10, 2012 at 9:56 AM, Geoffrey Sneddonwrote: It's not just Firefox addons that will break: GWT's output relies upon the exact format of Error.stack[1]. I know Google Wave depended upon this, and I believe other Google applications do too. Not

Re: Error stack

On Sun, Jun 10, 2012 at 9:56 AM, Geoffrey Sneddon wrote: > It's not just Firefox addons that will break: GWT's output relies upon the > exact format of Error.stack[1]. I know Google Wave depended upon this, and > I believe other Google applications do too. > Note that GWT can supply different def

Re: Error stack

On Sun, Jun 10, 2012 at 5:31 PM, Erik Arvidsson wrote: > On Sun, Jun 10, 2012 at 6:56 AM, Geoffrey Sneddon > wrote: > > As such, I'm somewhat dubious as to whether we can actually change the > > format that much without breaking sites. For reference, we support > > Error.stack (supposedly identic

Re: Error stack

No commonality is a problem if enough content detects implementations and depends on each one's .stack. Not sure this is true, just sayin' (ignoring implementation-specific dependencies, e.g. addons). The easy way out is Error.prototype.stackTrace, a getter that exposes, deeply and lazily, obj

Re: Error stack

There's no real consistency between any implementations of .stack. The only reason it needs to be a string is so that sites that blindly use .split() on it don't throw an exception. If you used JSON you could do the following output: {"message":"...","trace":[ {"source":"...", line:...}, {"sour

Re: Error stack

On 10 June 2012 22:44, Oliver Hunt wrote: > My original implementation in JSC was as an Array, but I found that there > were sites that depended on .stack being a string if it was present. Any > form of string encoding we expect to be machine parseable by necessity will > require escaping and fu

Re: Error stack

My original implementation in JSC was as an Array, but I found that there were sites that depended on .stack being a string if it was present. Any form of string encoding we expect to be machine parseable by necessity will require escaping and full format description. I've actually been tempte

Re: Error stack

On 10 June 2012 22:31, Erik Arvidsson wrote: > The thing is that software on the open web has to handle two different > formattings already to work correctly. The reason I picked the V8 > style over the SpiderMonkey style is that the SpiderMonkey style is > missing essential information like the

Re: Error stack

On Sun, Jun 10, 2012 at 6:56 AM, Geoffrey Sneddon wrote: > As such, I'm somewhat dubious as to whether we can actually change the > format that much without breaking sites. For reference, we support > Error.stack (supposedly identical to SpiderMonkey in format, though > obviously not) and Error.st

Re: Error stack

On 07/06/12 21:12, Jason Orendorff wrote: On Thu, Jun 7, 2012 at 1:37 PM, Erik Arvidsson 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 > >

Re: Error stack

Charles Kendrick wrote: On Fri, Jun 8, 2012 at 6:48 PM, Erik Arvidsson wrote: On Fri, Jun 8, 2012 at 4:10 PM, Charles Kendrick wrote: 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 relate

Re: Error stack

On Fri, Jun 8, 2012 at 6:48 PM, Erik Arvidsson wrote: > On Fri, Jun 8, 2012 at 4:10 PM, Charles Kendrick > wrote: >>> 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

Re: Error stack

On Fri, Jun 8, 2012 at 4:10 PM, Charles Kendrick wrote: >> 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 h

Re: Error stack

Almost - there are no arguments for the function that throws, as well as all functions between the function that throws and the one that catches. On Jun 8, 2012, at 4:53 PM, Brandon Benvie wrote: > Oh I see, the arguments of the just function that throws is unset. I didn't > get what you were

Re: Error stack

Oh I see, the arguments of the just function that throws is unset. I didn't get what you were saying at first. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack

No, this doesn't work. When you are in the catch() block you can discover the arguments for the function that contains the catch block and for any (non-recursive) functions further up the stack. But you cannot discover the arguments for functions that were on the stack when the error happened, bu

Re: Error stack

> 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

Re: Error stack

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 PageMai

Re: Error stack

On Fri, Jun 8, 2012 at 3:25 PM, Brandon Benvie 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/

Re: Error stack

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: , name: "InjectedScript._evaluate

Re: Error stack

On Fri, Jun 8, 2012 at 5:38 AM, Patrick Mueller 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). Th

Re: Error stack

> -- Forwarded message -- > From: Erik Arvidsson > To: es-discuss@mozilla.org > 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:

Re: Error stack

On Thu, Jun 7, 2012 at 11:57 PM, T.J. Crowder wrote: > On 8 June 2012 04:28, David Herman 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 struc

Re: Error stack

On Thu, Jun 7, 2012 at 3:21 PM, Charles Kendrick 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

Re: Error stack

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 JSO

Re: Error stack

On 8 June 2012 04:28, David Herman 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 str

Re: 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). 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

Re: Error stack

eJS/WinningJS-todo/commit/2d4ca10c4f672dac9f021b697c4c72bbff321ed9 > > > From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on > behalf of Erik Arvidsson [erik.arvids...@gmail.com] > Sent: Thursday, June 07, 2012 16:39 > To: Jason Orendorff > Cc: es-d

Re: Error stack

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.

RE: Error stack

ommit/2d4ca10c4f672dac9f021b697c4c72bbff321ed9 From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf of Erik Arvidsson [erik.arvids...@gmail.com] Sent: Thursday, June 07, 2012 16:39 To: Jason Orendorff Cc: es-discuss@mozilla.org Subject: Re: Error stack On Thu, Jun 7,

Re: Error stack

On Thu, Jun 7, 2012 at 1:12 PM, Jason Orendorff 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

Re: Error stack

On Thu, Jun 7, 2012 at 1:37 PM, Erik Arvidsson 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

Re: Error stack

It would be great to see this standardized! On Thu, Jun 7, 2012 at 12:17 PM, Erik Arvidsson wrote: > On Thu, Jun 7, 2012 at 12:05 PM, John J Barton > wrote: > > On Thu, Jun 7, 2012 at 11:37 AM, Erik Arvidsson > > wrote: > >> I wrote a new strawman for Error stack which is now available in some

Re: Error stack

On Thu, Jun 7, 2012 at 12:05 PM, John J Barton wrote: > On Thu, Jun 7, 2012 at 11:37 AM, Erik Arvidsson > 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:e

Re: Error stack

On Thu, Jun 7, 2012 at 11:37 AM, Erik Arvidsson 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