181914 - Derived Error objects cannot call constructor

Status: VERIFIED INVALID

(Rhino Graveyard :: Core, defect)

Description

[Jörg Schaible]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461)
Build Identifier: Rhino 1.5 release 4 0000 00 00 (in progress)

The description of ECMA 15.11 seem to imply that an Error object is a "normal" 
object and it should be possibly for an object of a dervied class to call its 
parent's constructor as usual. Unfortunately the message member will not be 
initialized as expected. See attached regression test.

Reproducible: Always

Steps to Reproduce:
Run regression test with Rhino or SpiderMonkey.
Actual Results:  
regression test fails.

Expected Results:  
regression test succeeds.

I am not really sure, if this is really an error. The ECMA description is not 
really clear about this case.

Comment 1

[Jörg Schaible]

Attachment: js\tests\ecma_3\Exceptions\regress-181914.js

Regression test for this case.

Comment 2

[Phil Schwartau]

cc'ing Waldemar on this one. Here is the heart of the testcase:


// derive MyCallError from Error
function MyCallError(msg)
{
  Error.call(this, msg);
}
MyCallError.prototype = new Error();
MyCallError.prototype.name = "MyCallError";
var err = new MyCallError('msg');


Note |err.name| gets successfully set:

js> err.name
MyApplyError

But |err.message| does not get set by |Error.call(this, msg)|
inside the MyApplyError() constructor:

js> err.message

js> err.message === '';
true



Jörg has provided a similar example using Error.apply:


// derive MyApplyError from Error
function MyApplyError(msg)
{
  Error.apply(this, arguments);
}
MyApplyError.prototype = new Error();
MyApplyError.prototype.name = "MyApplyError";
var err = new MyApplyError('msg');


The behavior is the same as above: |err.name| is set (of course),
but |err.message| does not get set inside the constructor. 

The behavior is the same in SpiderMonkey as in Rhino -

Comment 3

[Phil Schwartau]

Typo in my comment above:

> But |err.message| does not get set by |Error.call(this, msg)|
> inside the MyApplyError() constructor:

should be: 

> But |err.message| does not get set by |Error.call(this, msg)|
> inside the MyCallError() constructor:

Comment 4

[Waldemar Horwat]

The behavior you see is as specified by ECMA.  In 15.11.1, it states that the
function call Error(...) is equivalent to the object creation expression new
Error(...) with the same arguments.  This means that it creates and returns a
new Error object which has msg initialized properly.  See section 13.2.2: the
object creation expression creates and uses a new 'this' object.

The code you have throws away that new object.  To see this, change the function
slightly:

function MyCallError(msg)
{
  z = Error.call(this, msg);
}
MyCallError.prototype = new Error();
MyCallError.prototype.name = "MyCallError";
var err = new MyCallError('msg');

Now evaluate z:

js> z
Error: msg
js> z.message
msg

Comment 5

[Phil Schwartau]

Marking Verified; thanks to all -

Comment 6

[Jörg Schaible]

Hello all,

Hmmm. I am following quite exactly the User's Guide in Figure 8.6 
(http://developer.netscape.com/docs/manuals/js/core/jsguide15/obj2.html#1008499)
. While this is not the spec, the behaviour of the Error objects is somewhat 
unbalanced and surprising.

I've added a patch for Rhino, that realizes the "expected behaviour". I have to 
admit though, that the description in the User's Guide is never guaranteed by 
the spec at all. Although the generated object of 13.2.2-1 is used for 13.2.1, 
the problem arises with 13.2.2-7, that allows the [[contructor]] to ignore the 
object from 13.2.2-1. That prevents any reliable call of a superclass' 
constructor.

Comment 7

[Jörg Schaible]

Attachment: js\rhino\src\org\mozilla\javascript\NativeError.java.diff

Showcase for Rhino

Comment 8

[Jörg Schaible]

Attachment: js\tests\ecma_3\Exceptions\regress-181914.js

Updated regression test ensuring 15.11.1.1 for derived Error class.

Comment 9

[Jörg Schaible]

Attachment: js\tests\ecma_3\Exceptions\15.11.1.1.js

General regression test for 15.11.1.1

Comment 10

[Waldemar Horwat]

The ECMA spec is quite clear here, and both Rhino and Spidermonkey conform to
the spec.  The pattern mentioned in the user's guide in comment 6 applies to
user-defined objects but doesn't apply to built-in objects, including Date,
String, Number, Error, etc.  That's an unfortunate defect/feature of the
standard, but changing the standard would be a compatibility break and
gratuitously break existing web pages.

Comment 11

[Phil Schwartau]

Marking Verified.

I want to thank Waldemar for clarifying this issue, and Jörg
for such precise questions. I have added Jörg's two testcases
to the JS testsuite:

  mozilla/js/tests/ecma_3/Exceptions/15.11.1.1.js
  mozilla/js/tests/ecma_3/Exceptions/regress-181914.js

For the latter, I simply changed the use of |Error| to |_Error|,
a user-defined imitation of |Error|. This makes everything work.

Comment 12

[Jörg Schaible]

Hi Phil,

the regress-181914.js was somewhat obsolete now, since it did not really test 
something new concerning Exception regress testing. I've attached a (last <g>) 
patch for this regression test, that modifies your user-defined _Error class to 
be a real Error object and add an eighth test case ensuring this. Test runs 
fine.

Regards,
Jörg

Comment 13

[Jörg Schaible]

Attachment: js\tests\ecma_3\Exceptions\regress-181914.js.diff

Comment 14

[Phil Schwartau]

Jörg: good idea; I have checked in your improvements -

Comment 15

[Igor Bukanov]

Targeting as resolved against 1.5R4