119719 - Custom JS errors: filename/linenumber should default to location of throw

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect, P3)

Description

[Alex Vincent [:WeirdAl]]

Currently, Mozilla provides line number and file name information to JavaScript
errors which occur naturally:

try {
  var x = "A".toNumber();
  }
catch (e) {
  alert(e.lineNumber); // returns a number.  In my case, 8, because it's in XHTML.
  }

But, if I throw a custom error object, I don't get that pleasure.

try {
  var x = new Error("Hello World");
  throw x;
  }
catch (e) {
  alert(e.lineNumber); // returns 0
  }

I'm suggesting that if and only if the lineNumber and fileName properties have
not yet been set when the error is thrown, JSENG should set them to the line
number and file name from which the error was first thrown.

This means, by implication, that if an error is thrown and caught, and the
catching routine rethrows it, JSENG would reference the first throw statement's
line number and file name.

This would help a great deal in debugging efforts, I believe.

Comment 1

[Christopher Aillon (sabbatical, not receiving bugmail)]

See also (fixed) bug 50447

Comment 2

[Phil Schwartau]

Reassigning to rginda, as in bug 50447. Changing summary from 

   "Custom JS errors should have filename/linenumber properties" 
to
   "Custom JS errors: filename/linenumber should default to location of throw"


because in SpiderMonkey (but not Rhino), the Error() constructor
does admit parameters setting the fileName and lineNumber properties:


try
{
  throw new Error('A THROWN ERROR', '(FileName)', 999);
}
catch (e)
{
  var msg = 'CAUGHT ERROR: ' + e.message;
  msg += '\nFile Name = ' + e.fileName;
  msg  += '\nLine Number = ' + e.lineNumber;
  alert(msg);
}


OUTPUT:
js> load('../../tests/119719.js');

CAUGHT ERROR: A THROWN ERROR
File Name = (FileName)
Line Number = 999


But as Alex has stated above, the user wants to create a user-defined
error and not be forced to provide the fileName and lineNumber properties
when he invokes the constructor. They should be provided automatically,
as they are for natural errors, and should reflect the file and line
number at which the error is first thrown - 

Comment 3

[Henrik Gemal]

*** This bug has been marked as a duplicate of 52116 ***

Comment 4

[Phil Schwartau]

Reopening, because I think this is a separate issue occurring directly
within JS Engine, not the browser. SpiderMonkey provides default values
for the .fileName and .lineNumber properties for any error detected 
automatically by the engine. This bug has to do only with custom errors
made by the user. That is not what is being fixed in bug 52116 -

Comment 5

[Alex Vincent [:WeirdAl]]

Attachment: testcase

The testcase demonstrates how I perceive correct behavior in this instance. 
Opinions?

Comment 6

[Alex Vincent [:WeirdAl]]

Attachment: corrected testcase

I hate typos.

Comment 7

[Alex Vincent [:WeirdAl]]

rginda has requested via ChatZilla someone else take over this bug.  Any volunteers?

Comment 8

[Phil Schwartau]

Reassigning to khanson -

Comment 9

[Brendan Eich [:brendan]]

*** Bug 243869 has been marked as a duplicate of this bug. ***

Comment 10

[Brendan Eich [:brendan]]

Taking.

/be

Comment 11

[Brendan Eich [:brendan]]

*** Bug 271186 has been marked as a duplicate of this bug. ***

Comment 12

[Bob Clary [:bc] (inactive)]

js/tests/js1_5/Regress/regress-119719.js checked in.

Comment 13

[Bob Clary [:bc] (inactive)]

I am tempted to won't fix this. 

1) This is undefined by any standard. 
2) bug 50447 now sets the line number on user errors so the caveat "I'm
suggesting that if and only if the lineNumber and fileName properties have not
yet been set when the error is thrown" is never the case since the lineNumber
and fileName are _always_ set now.

Comment 14

[Bob Clary [:bc] (inactive)]

wontfix, please make a compelling case which will convince be if you really want
this.

Comment 15

[Brian Crowder]

I think we should unWONTFIX this; the behavior is definitely not what is expected.  Brendan:  what does ES4 say about this?

Comment 16

[Mike Shaver (:shaver emeritus)]

I'm wary of |throw obj;| mutating object, I have to say, but the debugging gains here are tempting nonetheless.

Comment 17

[Alex Vincent [:WeirdAl]]

shaver: I'd agree - per comment 0, I said if and only if they haven't been set first.  Otherwise, you could have:

try {
  throw new Error("foo");
} catch (e) {
  // ...
  throw e;
}

Comment 18

[Mike Shaver (:shaver emeritus)]

That still changes the object observably, which is my concern at the moment.

Comment 19

[Edwin van Vliet]

Think of a big library of code. Many classes, functions, etc, and the following 3 files:

file 1: lib.js
------------
function libThrow(e) {
   libYouWillNeverFindMe (e);
}

function libYouWillNeverFindMe(e) {
   throw e;
}
------------

file 2: err.js
------------
function createError(str) {
   return new Error(str);
}
------------

file 3: script in HTML document
------------
e = createError('Where did this come from?');
libThrow(e);
------------

This would be impossible to debug decently, since the Error Console reports the error on err.js, line 2, which is in fact useless information.

Developers expect to get the point from where the exception was thrown.

(And if you take it one step further: if some dynamic string is thrown, like the current date, no information about file or line number is available. Again it's impossible to locate the line of code that triggered the exception.)

So the information should be either attached to the Error, or be passed in another way. But it surely should be available to the developer.

Comment 20

[ash_mozilla]

See http://groups.google.com/group/mozilla.dev.tech.js-engine/browse_thread/thread/af195c5aafbfcb32#c60529630292209d for other issues related to this problem (specifically subclassing Error)

Comment 21

[Mike Shaver (:shaver emeritus)]

The "wha happened?" issue Edwin raises can be mitigated by having error console show the entire stack, FWIW.

Comment 22

[ash_mozilla]

(In reply to comment #21)
> The "wha happened?" issue Edwin raises can be mitigated by having error console
> show the entire stack, FWIW.
> 

Only partly, as the stack trace will never show |libYouWillNeverFindMe| or |libThrow|

Comment 24

[vidhi thakrar]

I think, lineNumber and fileName should be added to Error at the time of thorwing an error and not at the time of creating an Error.

Other Javascript Engine support this feature because it's very useful for developer to identify from where the error has been thrown.