284123 - Fails ecma_3/Exceptions/regress-181654.js section 2

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Bob Clary [:bc] (inactive)]

Passes in Mozilla 1.7, Fails in 1.7.6 and 1.8b2 trunk on winxp

STATUS: Calling toString for an object derived from the Error class should be
possible.
Failure messages were:
FAILED!: [reported from test()] Section 2 of test -
FAILED!: [reported from test()] Expected value '0', Actual value '-1'
FAILED!: [reported from test()]

Comment 1

[Igor Bukanov]

This is due to the fix for bug 260541. The test assumes the specific behaviour
of Error.toString() which is not defined by ECMA and is changed in SM after that
fix. So the test has to be changed like in:

Index: ecma_3/Exceptions/regress-181654.js
===================================================================
RCS file: /cvsroot/mozilla/js/tests/ecma_3/Exceptions/regress-181654.js,v
retrieving revision 1.6
diff -U3 -r1.6 regress-181654.js
--- ecma_3/Exceptions/regress-181654.js	13 Feb 2005 00:07:27 -0000	1.6
+++ ecma_3/Exceptions/regress-181654.js	2 Mar 2005 00:31:20 -0000
@@ -72,7 +72,7 @@
 
 status = inSection(2);
 var err2 = new MyError(err1);
-actual = examineThis(err2, err1);
+actual = examineThis(String(err2), err1);
 expect = EXPECTED_FORMAT;
 addThis();
 


 

Comment 2

[Bob Clary [:bc] (inactive)]

But that will result in a failure in the same section since the first argument
to examineThis will be a string, leading to an "undefined" when examineThis
tries to get its name property. 

Since bug 260541 changes the behavior of Error.prototype.toString when the name
or message properties contain something other than a string, should examineThis
be modified to take that into account or should section 2 just be removed
altogether? Personally, I think examineThis should be modified to reflect the
new behavior which will document the change when the test is run against older
spidermonkey builds. But what does Rhino do in this case?

Comment 3

[Igor Bukanov]

(In reply to comment #2)
> But that will result in a failure in the same section since the first argument
> to examineThis will be a string, leading to an "undefined" when examineThis
> tries to get its name property. 

Right, the intent was to change 
var err2 = new MyError(err1); 
to 
var err2 = new MyError(String(err1)); 

> 
> Since bug 260541 changes the behavior of Error.prototype.toString when the name
> or message properties contain something other than a string, should examineThis
> be modified to take that into account or should section 2 just be removed
> altogether? Personally, I think examineThis should be modified to reflect the
> new behavior which will document the change when the test is run against older
> spidermonkey builds. 

I do not have preferences how to change the test as long as it is generic enough
to cover the old and new behavior since both are within ECMAScript specs.

> But what does Rhino do in this case?

Rhino follows the old SM bahaviour. The SM code was changed to workaround
potential infinite recursion on string conversion since C does not allow to
handle a stack overflow in any reasonable way. JVM on the other hand alows to
handle that properly so given:

var e = new Error(); e.message=e; print(e)

Rhino shell properly reports:

js: exception from uncaught JavaScript throw: java.lang.StackOverflowError

Comment 4

[Bob Clary [:bc] (inactive)]

Ok, comment 3 changes checked in. 

Checking in regress-181654.js;
/cvsroot/mozilla/js/tests/ecma_3/Exceptions/regress-181654.js,v  <-- 
regress-181654.js
new revision: 1.7; previous revision: 1.6
done

Comment 5

[Bob Clary [:bc] (inactive)]

verified fixed.