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
> 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
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
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.
Comments:
- fat arrow : I am not a fan of the syntax but it is usefull and does
fix the unlogical behavior of |this| (the rules are the same for the
|this| binding, it does not change except that you must apply it to the
surrounding environment), the thin arrow (as soft binding's use I
suppos
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
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
Hi,
When Angus first published his blog post some people got the impression that
we're trying to either discredit TC39 and its efforts, or to replace it with
our own committee. We value TC39 and feel like they are doing a great job and
we have absolutely no interest in starting another committ
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
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
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
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
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@mozi
This is not a candidate for the core language standard, ECMA-262. Even
E4X, ECMA-357, a standard that failed to win adoption in browsers other
than Firefox, cannot validate against schema.
This is where you want a JS library. There are many choices, although
I'm no XML expert:
https://www.go
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Developing a ECMAScript based rich application I came across the
problem to validate a XML based config file against a XSD to be able
to leave out error handling during the config file processing in my code.
But it seems there's no standardized way
15 matches
Mail list logo
