From:  Ehsan Akhgari <ehsan.akhgari@gmail.com>
Date:  29 Sep 2016 00:25:47 Hong Kong Time
Newsgroup:  news.mozilla.org/mozilla.dev.tech.js-engine.internals
Subject:  

Re: Overriding Error constructors

NNTP-Posting-Host:  63.245.214.181

On 2016-09-27 5:44 PM, Bobby Holley wrote:
> I heard some years ago that there exist websites which sniffs UAs and
> invokes separate stack parsing routines for each browser. I have no idea
> if we'd hit significant breakage in practice, but it's worth being aware of.

Yeah, I'm quite worried about this too (since this is basically needed
to consume Error.stack at all for anything other than just displaying
verbatim.)

How about we add an embedding API which allows the embedder to choose
the format used in the stack formatting, where the default won't change,
but SpiderNode could put SpiderMonkey into the V8 stack emulation mode?

> On Tue, Sep 27, 2016 at 2:02 PM, Nick Fitzgerald
> > wrote:
> 
>     We could probably switch to V8's stack string format and save you some
>     trouble.
> 
>     * V8's format is more human readable
>     * Error().stack's format is not constrained by any standard, so in
>     theory
>     changing it is web compatible...
> 
> 
>     On Tue, Sep 27, 2016 at 1:54 PM, Ehsan Akhgari
>     >
>     wrote:
> 
>     > I'd like to emulate the format of the V8's stack property on Error
>     objects
>     > in SpiderNode.  The approach that I have tried is to override the
>     Error
>     > (and its family types) constructors on the global object with my
>     own which
>     > reformats the stack to emulate the V8 format.
>     >
>     > This works well for things such as |new Error('foo').stack|, but
>     it doesn't
>     > work for Errors generated by SpiderMonkey, since those are created
>     through
>     > ErrorObject::create() and as far as I can tell don't even look at the
>     > constructor for the Error object on the global object.
>     >
>     > Are there plans for changing this setup?
>     >
>     > Thanks,
>     > --
>     > Ehsan
>     > _______________________________________________
>     > dev-tech-js-engine-internals mailing list
>     > dev-tech-js-engine-internals@lists.mozilla.org
>     
>     > https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
>     
>     >
>     _______________________________________________
>     dev-tech-js-engine-internals mailing list
>     dev-tech-js-engine-internals@lists.mozilla.org
>     
>     https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
>     
> 
>