Last Comment Bug 56320 - Error() constructor doesn't work when called as a function
: Error() constructor doesn't work when called as a function
Status: RESOLVED FIXED
[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
Mentors:
Depends on:
Blocks:
  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:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


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

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

js> var x = new Error()
js> typeof(x)
object
Comment 3 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 
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.
Comment 4 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 rogerl (gone) 2000-10-12 16:19:19 PDT
Created attachment 16931 [details] [diff] [review]
set *rval to new object
Comment 6 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 
a=brendan@mozilla.org here, ask mccabe to do the same with r=, and ask further 
that we put this up for [rtm+].

/be
Comment 7 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 Mike McCabe 2000-10-30 11:44:52 PST
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.
Comment 9 Brendan Eich [:brendan] 2000-10-30 16:27:06 PST
Updating status whiteboard.

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

/be
Comment 12 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
treatment.
Comment 13 Boris Zbarsky [:bz] 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 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.