271180 - Error() should realize something that matches the nsIException interface

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[alexander :surkov (:asurkov)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616

I guess Error() and any internal exceptions should realize nsIException
interface because interface of Error() and internal exceptions is subset of
nsIException interface except stack property. I seem stack property is
unsuccessful analog of location property of nsIException interface.

If you need stack information then I think you choose nsIStackFrame interface
instead of string.

It is possible to save compatibility with early versions you can add realizing
nsIException interface and add stack property.

Reproducible: Always
Steps to Reproduce:

Comment 1

[Boris Zbarsky [:bzbarsky]]

nsIException is not part of the JavaScript engine, but rather part of the XPCOM
runtime.  Given that the JavaScript engine shouldn't depend on XPCOM, I don't
think we should be doing this (nor do I think there is a reasonable way to do it).

Comment 2

[Benjamin Smedberg]

bz: I think that if xpconnect did the magic it wouldn't be all that hard. I
truly don't understand why this is wanted/necessary, though.

Comment 3

[alexander :surkov (:asurkov)]

If javascript object realizes some XPCOM interface then it doesn't involve
disaster. And such object has not obvious dependency on XPCOM.

JavaScript exception object was extended by adding new property (stack
property). As I know ECMA script hasn't such property. I mean that location
property of nsIException is more powerful than stack property of javascript
exception object.

Comment 4

[alexander :surkov (:asurkov)]

Need to think about XPCOM interface realizing as adding new functionality to
ecma script standard. Don't think about it as dependency on XPCOM.

Comment 5

[Brendan Eich [:brendan]]

alexander: ECMA is not going to add anything like XPCOM or COM to the standard,
but perhaps a better stack or location property could be standardized.

But the dependency on XPCOM is a very real build issue to avoid.  The
SpiderMonkey engine is a C module that can stand alone (if JS_THREADSAFE, it
uses NSPR; otherwise it uses only standard C).  There are many users of it in
the world, and we do not want to impose XPCOM on them.  So any extension has to
be done using callbacks and other such techniques, to avoid imposing misordered
compile or link dependencies.

/be

Comment 6

[alexander :surkov (:asurkov)]

When I say "realizing of XPCOM interface" then I mean adding methods of
interface only. No more than. No any real link with XPCOM.

When I create javascript object witch have methods named as methods of some
XPCOM interface then I tell that my object realizes some XPCOM interface.

Comment 7

[Bob Clary [:bc] (inactive)]

unless someone objects, -> wontfix.

Comment 8

[Brendan Eich [:brendan]]

We need a proposal that's in the spirit of JS and more in the language of
ECMA-262 than "nsIException interface".  If someone writes such a specification,
please put it here and reopen.

/be

Comment 9

[alexander :surkov (:asurkov)]

I guess I put into words the idea vaguely. I mean the next:

//nsIStackFrame
function stackframe()
{
    this.caller=null;    //stackframe() object
    this.filename=null;
    this.language=null;
    this.lineNumber=null;
    this.name=null;
    this.sourceLine=null;

    this.toString=function(){}
}

//nsIException
function exception()
{
    this.columnNumber=null;
    /*etc*/
    stackframe=null;//stackframe() object
}

There is no any real link with XPCOM in example above. In fact I want a one
thing. It is replacing of property stack of Error() object with location
property like in nsIExpection interface (or add new property).

I suppose to change Error() object so that Error() object would be have
properties like in nsIExpeption interface.

Comment 10

[Brendan Eich [:brendan]]

That's not a spec, it's a very rought sketch.  It won't make sense to ECMA-262
readers or editors.  But if you insist, this bug can stay open.  I don't foresee
having time to work on it.

/be