Last Comment Bug 56320 - Error() constructor doesn't work when called as a function
: Error() constructor doesn't work when called as a function
[rtm-] fix in trunk
: js1.5
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: All All
P3 normal (vote)
: ---
Assigned To: rogerl (gone)
: Phil Schwartau
: Jason Orendorff [:jorendorff]
Depends on:
  Show dependency treegraph
Reported: 2000-10-12 14:51 PDT by David Flanagan
Modified: 2002-01-18 00:39 PST (History)
5 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

set *rval to new object (472 bytes, patch)
2000-10-12 16:19 PDT, rogerl (gone)
no flags Details | Diff | Splinter Review

Description User image David Flanagan 2000-10-12 14:51:49 PDT
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 User image David Flanagan 2000-10-12 14:53:43 PDT
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 User image Phil Schwartau 2000-10-12 15:58:18 PDT
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)
Comment 3 User image Phil Schwartau 2000-10-12 16:08:53 PDT
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 User image rogerl (gone) 2000-10-12 16:17:48 PDT
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.
Comment 5 User image rogerl (gone) 2000-10-12 16:19:19 PDT
Created attachment 16931 [details] [diff] [review]
set *rval to new object
Comment 6 User image Brendan Eich [:brendan] 2000-10-26 18:54:27 PDT
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+].

Comment 7 User image selmer (gone) 2000-10-29 08:38:09 PST
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?
Comment 8 User image Mike McCabe 2000-10-30 11:44:52 PST

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.
Comment 9 User image Brendan Eich [:brendan] 2000-10-30 16:27:06 PST
Updating status whiteboard.

Comment 10 User image selmer (gone) 2000-10-30 18:28:08 PST
rtm-, still don't see any impacted sites mentioned.  The train is leaving and 
we're not looking for general cleanup fixes.
Comment 11 User image Brendan Eich [:brendan] 2000-10-30 19:34:08 PST
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 User image David Flanagan 2000-10-31 15:57:01 PST
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
Comment 13 User image Boris Zbarsky [:bz] (still a bit busy) 2000-11-29 07:58:33 PST
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 User image rogerl (gone) 2000-11-29 17:56:19 PST
Not a 6.01 thing.

Note You need to log in before you can comment on or make changes to this bug.