Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Error() constructor doesn't work when called as a function




JavaScript Engine
17 years ago
16 years ago


(Reporter: David Flanagan, Assigned: rogerl (gone))




Firefox Tracking Flags

(Not tracked)


(Whiteboard: [rtm-] fix in trunk)


(1 attachment)



17 years ago
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

Comment 1

17 years ago
oops.  I forgot to mention.  What Error() does when called as a function
is to simply return undefined.  It should return an Error object

Comment 2

17 years ago
This is what I'm getting in the JS shell (pulled 2000-10-11):

js> var x = Error()
js> typeof(x)

js> var x = new Error()
js> typeof(x)


17 years ago
OS: Linux → All

Comment 3

17 years ago
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.

Comment 4

17 years ago
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.
Ever confirmed: true

Comment 5

17 years ago
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 here, ask mccabe to do the same with r=, and ask further 
that we put this up for [rtm+].

Keywords: js1.5, rtm

Comment 7

17 years ago
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?
Whiteboard: [rtm need info]

Comment 8

17 years ago

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.

David Flanagan is doing another edition of his JavaScript book, and he's been
filing bugs and indicating his desire not to have to say that Mozilla isn't

Easy safe step towards standards conformance, recommending rtm.
Whiteboard: [rtm need info] → [rtm+]
Updating status whiteboard.

Whiteboard: [rtm+] → [rtm+] fix in trunk

Comment 10

17 years ago
rtm-, still don't see any impacted sites mentioned.  The train is leaving and 
we're not looking for general cleanup fixes.
Whiteboard: [rtm+] fix in trunk → [rtm-] fix in trunk
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.


Comment 12

17 years ago
The reason that there are no impacted sites is that the Error() constructor
is new in JavaScript 5.5.  No one is using it yet, which makes it all the more
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


17 years ago
Hardware: PC → All

Comment 13

17 years ago
are we keeping this one open for 6.01, or should it be marked as fixed since the
fix is in the trunk?

Comment 14

17 years ago
Not a 6.01 thing.
Last Resolved: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.