The ECMA v3 spec says (15.11.1) that when Error() is called as
a function it works just as when it is called as a constructor.
The same goes for the other Error types like TypeError().
This doesn't work right in js-1.5-rc1
oops. I forgot to mention. What Error() does when called as a function
is to simply return undefined. It should return an Error object
This is what I'm getting in the JS shell (pulled 2000-10-11):
js> var x = Error()
js> var x = new Error()
Here is the relevant passage from ECMA Version 3:
15.11 Error Objects
Instances of Error objects are thrown as exceptions when runtime errors occur.
The Error objects may also serve as base objects for user-defined exception
15.11.1 The Error Constructor Called as a Function
When Error is called as a function rather than as a constructor, it creates and
initialises a new Error object. Thus the function call Error(…) is equivalent to
the object creation expression new Error(…) with the same arguments.
The Exception super-duper constructor doesn't set rval for the not-constructing
case. Here's a patch. Don't think this is rtm level though.
Created attachment 16931 [details] [diff] [review]
set *rval to new object
This was fixed on the trunk a while ago. I don't think the fix got into the
branch, but it should be considered for standards-conformance reasons. We have
a patch that already got reviewed as part of a larger patch. I'll re-record my
email@example.com here, ask mccabe to do the same with r=, and ask further
that we put this up for [rtm+].
Marking [rtm need info] since this is in progress. Brendan, you mention
standards conformance, but what real world sites would be broken by this? If
it's just future compatibility, then this seems like just another bug (and the
trunk is already fixed.)
What could possibly be broken by taking this fix?
Nothing could possibly be broken by this fix.
It corrects an oversight in which an out parameter (already set to safe
'undefined' value) wasn't set to the needed value. We were already doing *all*
of the work to create the value, just neglecting to return it. The function in
question is part of a pattern that occurs throughout the JS engine, and making
this case work correctly (instead of quietly returning undefined) will not
introduce any new behavior, just fix old behavior.
filing bugs and indicating his desire not to have to say that Mozilla isn't
Easy safe step towards standards conformance, recommending rtm.
Updating status whiteboard.
rtm-, still don't see any impacted sites mentioned. The train is leaving and
we're not looking for general cleanup fixes.
Standards conformance fixes are not "general" cleanup, they're specific, as in,
follow the specification. I believe jst plead a similar bug (case sensitivity
in one HTML DOM method vs. insensitivity in the standard and in another that we
implement correctly). These are one-line fixes that make the product better in
specific, standardized ways. I don't see why they are less important than other
specific fixes for crash and data-loss bugs, although I appreciate the PDT's
efforts to close down changes and get the train moving.
The reason that there are no impacted sites is that the Error() constructor
frustrating to release a product in which it doesn't work right!
It was my understanding that one of the marketing points for Netscape 6 was
that it would feature better standards compliance than Microsoft's browser.
So it surprises me that standards-conformance bugs don't get higher priority
are we keeping this one open for 6.01, or should it be marked as fixed since the
fix is in the trunk?
Not a 6.01 thing.