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

RESOLVED FIXED

Status

()

Core
JavaScript Engine
P3
normal
RESOLVED FIXED
17 years ago
16 years ago

People

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

Tracking

({js1.5})

Trunk
js1.5
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [rtm-] fix in trunk)

Attachments

(1 attachment)

(Reporter)

Description

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
(Reporter)

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)
undefined

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

Updated

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 
classes.



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.
(Assignee)

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.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
(Assignee)

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

/be
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
r=mccabe.

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
standards-compliant.

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

/be
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.

/be
(Reporter)

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
treatment.

Updated

17 years ago
Hardware: PC → All
are we keeping this one open for 6.01, or should it be marked as fixed since the
fix is in the trunk?
(Assignee)

Comment 14

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