Alex Vincent [:WeirdAl] Reporter
	Description • 23 years ago

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.

	Christopher Aillon (sabbatical, not receiving bugmail)
	Comment 1 • 23 years ago

See also (fixed) bug 50447

	Phil Schwartau
	Comment 2 • 23 years ago

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 - 

	Henrik Gemal
	Comment 3 • 23 years ago

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

	Phil Schwartau
	Comment 4 • 23 years ago

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 -

	Alex Vincent [:WeirdAl] Reporter
	Comment 5 • 23 years ago

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

	Alex Vincent [:WeirdAl] Reporter
	Comment 6 • 23 years ago

I hate typos.

	Alex Vincent [:WeirdAl] Reporter
	Comment 7 • 23 years ago

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

	Phil Schwartau
	Comment 8 • 23 years ago

Reassigning to khanson -

	Brendan Eich [:brendan] Assignee
	Comment 9 • 21 years ago

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

	Brendan Eich [:brendan] Assignee
	Comment 10 • 21 years ago

Taking.

/be

	Brendan Eich [:brendan] Assignee
	Comment 11 • 20 years ago

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

	Bob Clary [:bc] (inactive)
	Comment 12 • 20 years ago

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

	Bob Clary [:bc] (inactive)
	Comment 13 • 20 years ago

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.

	Bob Clary [:bc] (inactive)
	Comment 14 • 20 years ago

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

	Brian Crowder
	Comment 15 • 17 years ago

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

	Mike Shaver (:shaver -- probably not reading bugmail closely)
	Comment 16 • 17 years ago

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

	Alex Vincent [:WeirdAl] Reporter
	Comment 17 • 17 years ago

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;
}

	Mike Shaver (:shaver -- probably not reading bugmail closely)
	Comment 18 • 17 years ago

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

	Edwin van Vliet
	Comment 19 • 17 years ago

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.

	ash_mozilla
	Comment 20 • 17 years ago

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)

	Mike Shaver (:shaver -- probably not reading bugmail closely)
	Comment 21 • 17 years ago

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

	ash_mozilla
	Comment 22 • 17 years ago

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

	vidhi thakrar
	Comment 24 • 11 years ago

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.