ES4 draft: Error classes
This may sound like a stupid question, but...
Adding file and line info to an Error instance seems to be a good thing. Should the standard include two read-only properties "fileName" and "line" that an implementation may choose to fill in during construction, and that return, say, the empty string and -1 if not supported?
SpiderMonkey and ExtendScript both support these properties.
Michael
On 7 Mar 2008, at 08:02, Michael Daumling wrote:
This may sound like a stupid question, but...
Adding file and line info to an Error instance seems to be a good
thing. Should the standard include two read-only properties "fileName" and "line" that an implementation may choose to fill in during
construction, and that return, say, the empty string and -1 if not supported?SpiderMonkey and ExtendScript both support these properties.
Michael
I'm for this, and on a similar tact make it easier to subclass error
to create custom user Error classes. Currently in Spidermonkey you
have to jump through the following hoops to get an Error subclass with
filename and linenumber properties:
groups.google.com/group/mozilla.dev.tech.js-engine/browse_thread/thread/af195c5aafbfcb32
I forget all the problems, but from memory the main one is that:
MyError = function() {}; MyError.prototype = Error.prototype;
Doesn't do what you'd expect. And doing
MyError.prototype = new Error();
Is no good since then the filename and linenumber will be of that
line, not where you create the MyError instance.
Ash
2008/3/7 Ash Berlin <ash_es4 at firemirror.com>:
I forget all the problems, but from memory the main one is that:
MyError = function() {}; MyError.prototype = Error.prototype;
Doesn't do what you'd expect. And doing
MyError.prototype = new Error();
Is no good since then the filename and linenumber will be of that line, not where you create the MyError instance.
Right, and the idea of mutating an object when it's thrown in order to reset its stack information seems bogus.
What about Error.prototype.throw, which would throw |this|, and act as a hook for the stack/location setting implementation behaviour? We might want to permit an implementation to elide the Error.prototype.throw frame itself in whatever stack reflection is provided (though if E.p.throw has an internal error of some kind, it should probably be visible in the trace).
(We could also put it on Object.prototype, which would make |e.throw()| work for almost all values of e rather than just Errors, but that might be a bit beyond the pale.)
Mike
-----Original Message----- From: es4-discuss-bounces at mozilla.org [mailto:es4-discuss-bounces at mozilla.org] On Behalf Of Mike Shaver Sent: 7. mars 2008 03:34 To: es4-discuss Discuss Subject: Re: ES4 draft: Error classes
2008/3/7 Ash Berlin <ash_es4 at firemirror.com>:
I forget all the problems, but from memory the main one is that:
MyError = function() {}; MyError.prototype = Error.prototype;
Doesn't do what you'd expect. And doing
MyError.prototype = new Error();
Is no good since then the filename and linenumber will be of that line, not where you create the MyError instance.
Right, and the idea of mutating an object when it's thrown in order to reset its stack information seems bogus.
What about Error.prototype.throw, which would throw |this|, and act as a hook for the stack/location setting implementation behaviour? We might want to permit an implementation to elide the Error.prototype.throw frame itself in whatever stack reflection is provided (though if E.p.throw has an internal error of some kind, it should probably be visible in the trace).
Not really endorsing any of these ideas as of yet, would like to see a concrete proposal with details fleshed out.
The chances that the spec will require a useful backtrace (quasi-fixed format and requirements about which frames may or may not be in it, say) or source location information to be created for E.p.throw are probably quite low. Realistically what we could hope for is a statement of intent and well-defined hooks for implementations who want to support something, like the case is for the ControlInspector proposal (which is optional). Adding file/line info to errors thrown by the language implementation looks easier to do across diverse runtimes, but I don't know for sure.
On Fri, Mar 7, 2008 at 7:31 AM, Lars Hansen <lhansen at adobe.com> wrote:
The chances that the spec will require a useful backtrace (quasi-fixed format and requirements about which frames may or may not be in it, say) or source location information to be created for E.p.throw are probably quite low. Realistically what we could hope for is a statement of intent and well-defined hooks for implementations who want to support something, like the case is for the ControlInspector proposal (which is optional). Adding file/line info to errors thrown by the language implementation looks easier to do across diverse runtimes, but I don't know for sure.
Indeed, I wasn't expecting anything normative other than that E.p.throw threw |this|, but informative (SHOULD? MAY?) text describing it as a place for implementors to hook state modifications to aid in diagnosis.
I'll see if I can figure out how to write a concrete proposal, maybe next week; please feel free to beat me to this, lazylist!
Mike
I think that adding backtrace information is overkill for the spec. Collecting this information should be left to a debugging environment.
What I would suggest is something along the following lines. It should be made clear that these properties must be present, but that the actual value of these properties are implementation dependent. This creates a reliable framework for returning extended error information to be used in error logging or error display.
fileName
The initial value of the fileName prototype property is an implementation-defined string that reflects the name of the source file containing the script that created the Error instance.
The implementation of this property is optional. If not implemented, the value of this property is the empty string.
line
The initial value of the line prototype property is the line number of the executing code that created the Error instance. This is an integer value, starting with the number 1.
The implementation of this property is optional. If not implemented, than value of this property is zero.
Michael
On 09/03/2008, Michael Daumling <mdaeumli at adobe.com> wrote:
What I would suggest is something along the following lines. It should be made clear that these properties must be present, but that the actual value of these properties are implementation dependent. This creates a reliable framework for returning extended error information to be used in error logging or error display.
fileName
The initial value of the fileName prototype property is an implementation-defined string that reflects the name of the source file containing the script that created the Error instance.
The implementation of this property is optional. If not implemented, the value of this property is the empty string.
line
The initial value of the line prototype property is the line number of the executing code that created the Error instance. This is an integer value, starting with the number 1.
The implementation of this property is optional. If not implemented, than value of this property is zero.
How about javascript: urls; javascript in data: urls; javascript from eval, setTimeout with string, setInterval with string, Function constructor; javascript written directly into the page using DOM; javascript written directly into the page using innerHTML?
On 3/9/08, Michael Daumling <mdaeumli at adobe.com> wrote:
I think that adding backtrace information is overkill for the spec. Collecting this information should be left to a debugging environment.
What I would suggest is something along the following lines. It should be made clear that these properties must be present, but that the actual value of these properties are implementation dependent. This creates a reliable framework for returning extended error information to be used in error logging or error display.
fileName
The initial value of the fileName prototype property is an implementation-defined string that reflects the name of the source file containing the script that created the Error instance.
The implementation of this property is optional. If not implemented, the value of this property is the empty string.
line
The initial value of the line prototype property is the line number of the executing code that created the Error instance. This is an integer value, starting with the number 1.
The implementation of this property is optional. If not implemented, than value of this property is zero.
I object to these suggestions on principle because they reveal information about the caller of a function (the one invoking "new Error") to the function (the Error constructor), which in turn reveals it to arbitrary code (the code catching the exception). Now you can say that file name and line number is not very sensitive information, but my claim is that it mildly reveals details about the structure of the application and the computer the application originated on. I don't think this is excellent design. (It also messes up tail calls, and it is brittle because it only works one level up.)
Another problem is that, unless we expose this funcitonality ("grub around in my caller and extract attributes of the code there") as a primitive, then this is more functionality that "we" (language implementers) can provide that "they" (language users) can't mimic. Clearly there will be some functionality like that, but we should use it sparingly. And it seems clear to me that that functionality should not be exposed as a primitive.
Better then, perhaps, to introduce a 'sourcecontext' nullary operator that packages up this information and allows it to be passed to the Error constructor:
new Error("foo! this program is broken", sourcecontext)
(Inspired by FILE and LINE in C, of course. And maybe those are better names, all things considered.)
I agree that file and line information is not really sensitive information. I believe, however, that since the implementation can choose to provide this information to the Error constructor, the implementation has full control about whether to provide that information or not. We (the language designers) only offer a standardized way to provide this information.
Insofar, I think that your principle is worthy and honorable, but it does not unconditionally apply to this specific situation.
The sourcecontext idea falls a bit short IMHO. It would be good to have for a ES4 program throwing the error. But what about all runtime errors, like RangeError, EvalError and the like? Why would you object to the ability to display a comprehensive error message to the user - if the implementation chooses to supply file and line information?
Michael
On Mar 9, 2008, at 3:31 AM, Michael Daumling wrote:
line
The initial value of the line prototype property is the line number of the executing code that created the Error instance. This is an integer value, starting with the number 1.
FYI, this property is named lineNumber in SpiderMonkey -- consonant
with fileName, if a bit verbose to match.
On Sun, Mar 9, 2008 at 12:11 PM, Michael Daumling <mdaeumli at adobe.com> wrote:
I agree that file and line information is not really sensitive information.
I disagree: we have existing bugs in Mozilla about the security impact of exposing filename information to unprivileged callers. It's likely that we'll be able to solve them without removing all filename information, but it's certainly not always that case that the obvious option (full file path) is trivially safe. Spec text that encouraged this behaviour would need to be clear about possible risks, I think, even if it's ultimately left to the implementation.
Mike
On Mar 9, 2008, at 7:45 AM, liorean wrote:
How about javascript: urls; javascript in data: urls; javascript from eval, setTimeout with string, setInterval with string, Function constructor; javascript written directly into the page using DOM; javascript written directly into the page using innerHTML?
All excellent "hard cases", and not as uncommon as you might think. See
On Mar 9, 2008, at 3:31 AM, Michael Daumling wrote:
line
The initial value of the line prototype property is the line number of the executing code that created the Error instance. This is an integer value, starting with the number 1.
On 09/03/2008, Brendan Eich <brendan at mozilla.org> wrote:
FYI, this property is named lineNumber in SpiderMonkey -- consonant with fileName, if a bit verbose to match.
I remember writing an error handler that provided cross browser as-much-information-as-the-browser-provides data about errors. (The code is sadly gone together with the domain I used it on, however, so I can't look it up.)
I recall there was some engine that used the name lineNo for that (together with a property for getting the column number I think, though I can't recall the name). There was also some engine using the name source for the file name.
-----Original Message----- From: Michael Daumling Sent: 9. mars 2008 10:12 To: Lars T Hansen Cc: Lars Hansen; Mike Shaver; es4-discuss Discuss Subject: RE: ES4 draft: Error classes
I agree that file and line information is not really sensitive information. I believe, however, that since the implementation can choose to provide this information to the Error constructor, the implementation has full control about whether to provide that information or not. We (the language designers) only offer a standardized way to provide this information.
Insofar, I think that your principle is worthy and honorable, but it does not unconditionally apply to this specific situation.
The sourcecontext idea falls a bit short IMHO. It would be good to have for a ES4 program throwing the error. But what about all runtime errors, like RangeError, EvalError and the like? Why would you object to the ability to display a comprehensive error message to the user - if the implementation chooses to supply file and line information?
I don't object to that. I object to arbitrary code being able to get a hold of source information by catching an exception. I know that at least Opera prints a backtrace in the JS console on uncaught errors, and users like that. But that backtrace need not be stored in the error object, it can be generated when the run-time system observes that the exception was (or will be) uncaught. (This is more general too, since it means the backtrace can be printed even if the user code throws "undefined" but fails to catch it.) Again, good debugging support really wants to break abstraction and security boundaries and should therefore not obviously be supported directly in the language.
I have a competing proposal which I will post shortly.
(Didn't know who to follow up to so lamely following up to myself.)
Straw proposal for debugging information and backtraces in error objects.
Problems to solve
-
Debugging info (file name, line number, backtrace) are useful in Error instances thrown by the program
-
If not captured automatically, there needs to be a really simple way for the programmer to state that debugging information should be captured (or to capture the information)
Issues to watch out for:
-
Security / privacy problems if debugging information can leak to arbitrary code (realistic attack scenario).
-
Code that gets to look into the caller's lexical environment is hard to control, makes possibly unwarranted assumptions about the implementation, may preclude tail calls. So "magic" functionality comes at a cost.
Proposal
-
New property Error.prototype.context, value null
-
New property Error.prototype.backTrace, value null
-
When the run-time system throws a standard error object under well-defined circumstances (eg, when it throws a TypeError because a value of an incompatible type is stored in a type-annotated property) then it may, at its discretion, create properties "context" and "backTrace" on the new error object. The values in these properties will reveal information about the static and dynamic location of the error.
The property "context" is either null, or it is a dynamic object with three properties "scheme", "data", and "line". "scheme" and "data" are strings. "line" is a nonnegative integer.
The "scheme" denotes the type of the source ("file", "eval", "new Function", "javascript:", "data:"; a full list will need to be created and will partly be embedding dependent) and the "data" are interpreted relative to the "scheme" (eg, for "file", "data" would be a file name). "scheme" may be the empty string, in which case "data" should be ignored; "data" may be the empty string even if "scheme" is not. The "line", if not 0, denotes a line number (following line terminator normalization) inside the source denoted by "scheme" and "data".
The property "backTrace", if not null, must be an array of objects of the same type as stored in "context", representing a stack trace taken at the point of the creation of the error object. The object at property 0 in "backTrace" represents the innermost stack frame and is the same object that is stored in the "context" property.
IMPLEMENTATION NOTES.
Implementations are not required to support this functionality at all except in providing the two properties of the Error prototype object.
Implementations are encouraged to support the context and backTrace properties only in a debugging mode that must be explicitly enabled, and to reveal the minimum amount of information through this interface.
Implementations are encouraged to make the innermost frame and the backTrace "relevant", ie, to filter system frames that the program can't expect to process.
-
New subclass of Error called AssertionError
-
New expression forms assert(E), assert(E1,E2)
assert is a new keyword (an operator name). In these expressions, the parentheses are not optional.
assert(E) evaluates E and converts the result to boolean.
If the converted value is true, the result of the expression is the value of E. Otherwise, a new AssertionError instance is thrown.assert(E1,E2) evaluates E1 and converts the result to boolean. If the converted value is true, the result of the expression is the value of E1. Otherwise, E2 is evaluated to yield a new object instance, which is thrown.
When an assertion expression results in a thrown exception value V the run-time system should initialize the "context" and "backTrace" fields of V, provided the type of V is a subclass of Error.
Very generic, and easily expandable - I like it! This proposal provides enough optional information for error dialogs.
Clarification question: Wouldn't the context and backTrace properties be instance properties, not prototype properties? The Error prototype object would contain these two properties set to null, and thrown Error instances would possibly contain instance-specific data that shadows the prototype properties if present?
Michael
-----Original Message----- From: Michael Daumling Sent: 18. mars 2008 06:21 To: Lars Hansen; es4-discuss Discuss Subject: RE: ES4 draft: Error classes
Very generic, and easily expandable - I like it! This proposal provides enough optional information for error dialogs.
Clarification question: Wouldn't the context and backTrace properties be instance properties, not prototype properties? The Error prototype object would contain these two properties set to null, and thrown Error instances would possibly contain instance-specific data that shadows the prototype properties if present?
Since these objects are written in the ES3 style, the prototype objects provide default values and context/backTrace are added to the error objects as appropriate. So what you're presumably objecting to is that the description does not make explicit note of the fact that context/backTrace properties can show up on various error instances too. Noted.
(However, in all contexts they are dynamic properties, and not instance properties in the "class" sense. The Error prototype object is not actually an instance of Error, it is an Object with various tweaks.)
No objections - just dumb questions, Lars! After all these years implementing and working with JavaScript, some formal aspects are still cloudy to me :))
Michael
On Mon, Mar 17, 2008 at 12:11 PM, Lars Hansen <lhansen at adobe.com> wrote:
(Didn't know who to follow up to so lamely following up to myself.)
Straw proposal for debugging information and backtraces in error objects.
Issues to watch out for:
Security / privacy problems if debugging information can leak to arbitrary code (realistic attack scenario).
Code that gets to look into the caller's lexical environment is hard to control, makes possibly unwarranted assumptions about the implementation, may preclude tail calls. So "magic" functionality comes at a cost.
Proposal
New property Error.prototype.context, value null
New property Error.prototype.backTrace, value null
When the run-time system throws a standard error object under well-defined circumstances (eg, when it throws a TypeError because a value of an incompatible type is stored in a type-annotated property) then it may, at its discretion, create properties "context" and "backTrace" on the new error object. The values in these properties will reveal information about the static and dynamic location of the error.
How does the stack trace get set? Given a user-defined Error type - IllegalDateFormatError - what do callers of the DateFormat have to do to make functions "capture" the stack trace?
The property "backTrace", if not null, must be an array of objects of the same type as stored in "context", representing a stack trace taken at the point of the creation of the error object. The object at property 0 in "backTrace" represents the innermost stack frame and is the same object that is stored in the "context" property.
Should the stack trace be - backTrace - or - stackTrace - ?
New subclass of Error called AssertionError
New expression forms assert(E), assert(E1,E2)
What does this have to do with getting a stack trace?
Garrett
-----Original Message----- From: Garrett Smith [mailto:dhtmlkitchen at gmail.com] Sent: 18. mars 2008 11:57 To: Lars Hansen Cc: es4-discuss Discuss Subject: Re: ES4 draft: Error classes
On Mon, Mar 17, 2008 at 12:11 PM, Lars Hansen <lhansen at adobe.com> wrote:
(Didn't know who to follow up to so lamely following up to myself.)
Straw proposal for debugging information and backtraces in error objects.
Issues to watch out for:
Security / privacy problems if debugging information can leak to arbitrary code (realistic attack scenario).
Code that gets to look into the caller's lexical environment is hard to control, makes possibly unwarranted assumptions about the implementation, may preclude tail calls. So "magic" functionality comes at a cost.
Proposal
New property Error.prototype.context, value null
New property Error.prototype.backTrace, value null
When the run-time system throws a standard error object under well-defined circumstances (eg, when it throws a TypeError because a value of an incompatible type is stored in a type-annotated property) then it may, at its discretion, create properties "context" and "backTrace" on the new error object. The values in these properties will reveal information about the static and dynamic location of the error.
How does the stack trace get set? Given a user-defined Error type - IllegalDateFormatError - what do callers of the DateFormat have to do to make functions "capture" the stack trace?
Read further.
The property "backTrace", if not null, must be an array of objects of the same type as stored in "context", representing a stack trace taken at the point of the creation of the error object. The object at property 0 in "backTrace" represents the innermost stack frame and is the same object that is stored in the "context" property.
Should the stack trace be - backTrace - or - stackTrace - ?
New subclass of Error called AssertionError
New expression forms assert(E), assert(E1,E2)
What does this have to do with getting a stack trace?
See your question above.
+1 to Lars Error context/backTrace proposal.
Can we also have something like #file and #line, so that the various
Javascript translators (ours, Dojo, various compressors, etc.) can
relate context back to the original source, rather than the executed
source?
-----Original Message----- From: P T Withington [mailto:ptwithy at gmail.com] On Behalf Of P T Withington Sent: 20. mars 2008 07:41 To: Lars Hansen Cc: es4-discuss Discuss Subject: Re: ES4 draft: Error classes
+1 to Lars Error context/backTrace proposal.
Can we also have something like #file and #line, so that the various Javascript translators (ours, Dojo, various compressors, etc.) can relate context back to the original source, rather than the executed source?
Strawman proposal that avoids compounding our syntax woes.
Syntax:
A comment of this form preceded on the same line only by whitespace:
/**es:context=<scheme>;<data>;<line>*/
Space characters are not allowed anywhere except within <scheme> and <data>, where it is interpreted literally. Line terminators are not
allowed anywhere. Line terminator characters in scheme and data should be encoded using \x or \u syntax.
Semantics:
The meaning of scheme, data, and line are as for the context/backTrace proposal. The intent is that the values provided here override the values that would be provided by the implementation in a source context object.
A value for scheme, data, and line field must only be provided if values are provided for the fields to its left. Field values default to the values from the previous instance of the directive. Initial fields values are the scheme and data the implementation would report absent any annotation, and a line of 1.
Conformance:
An ES4 implementation is free not to support this facility at all.
To support this facility means to understand the directives and to report the values provided in the directives in error messages and in the context/backTrace facility, if that is supported.
Example:
/*es:context=file name;test.es;1/ /*es:context=;;7/
On Thu, Mar 20, 2008 at 12:27 PM, Lars Hansen <lhansen at adobe.com> wrote:
A comment of this form preceded on the same line only by whitespace:
/**es:context=<scheme>;<data>;<line>*/
We did this with // comments in SpiderMonkey, because the directives are inherently related to a line, and it avoids questions about whether the line numbering indicates the first or last line of the comment containing the directive. We didn't care a lot about lines getting overlong, since they're virtually always produced by tools as a way for people to not look at the source containing them. :)
Mike
-----Original Message----- From: Mike Shaver [mailto:mike.shaver at gmail.com] Sent: 20. mars 2008 09:44 To: Lars Hansen Cc: P T Withington; es4-discuss Discuss Subject: Re: ES4 draft: Error classes
On Thu, Mar 20, 2008 at 12:27 PM, Lars Hansen <lhansen at adobe.com> wrote:
A comment of this form preceded on the same line only by whitespace:
/**es:context=<scheme>;<data>;<line>*/
We did this with // comments in SpiderMonkey, because the directives are inherently related to a line, and it avoids questions about whether the line numbering indicates the first or last line of the comment containing the directive.
We didn't care a lot about lines getting overlong, since they're virtually always produced by tools as a way for people to not look at the source containing them. :)
OK, that's good feedback. What's the SpiderMonkey syntax?
It would be better to go with something that is already in
use, even if I expect the proposal here is a little more
elaborate.
The funny thing is that I went to some trouble in my previous writeup to disallow line terminators without drawing the obvious conclusion that I could switch to // style comments... Yay, time for more coffee.
On Thu, Mar 20, 2008 at 12:52 PM, Lars Hansen <lhansen at adobe.com> wrote:
OK, that's good feedback. What's the SpiderMonkey syntax? It would be better to go with something that is already in use, even if I expect the proposal here is a little more elaborate.
//@line 123 "awesomeLib.js" throw Error("ow");
The error's line number is 123, file is "awesomeLib.js". We have some bits in there like a limit on the filename length (1024) and a cap on the line length (10x our "natural" line length, I think); eminently negotiable.
I'm not sure we turned it on for content, because of spoofing concerns, but I'm pretty sure we use it for our chrome.
Mike
-----Original Message----- From: Mike Shaver [mailto:mike.shaver at gmail.com] Sent: 20. mars 2008 11:44 To: Lars Hansen Cc: P T Withington; es4-discuss Discuss Subject: Re: ES4 draft: Error classes
On Thu, Mar 20, 2008 at 12:52 PM, Lars Hansen <lhansen at adobe.com> wrote:
OK, that's good feedback. What's the SpiderMonkey syntax? It would be better to go with something that is already in use, even if I expect the proposal here is a little more elaborate.
//@line 123 "awesomeLib.js" throw Error("ow");
The error's line number is 123, file is "awesomeLib.js". We have some bits in there like a limit on the filename length (1024) and a cap on the line length (10x our "natural" line length, I think); eminently negotiable.
OK. We would need to accomodate other input sources than files at a minimum, maybe an optional string at the end (the file name could be optional too).
I'm not sure we turned it on for content, because of spoofing concerns, but I'm pretty sure we use it for our chrome.
If you could dig up a discussion thread or actual person to illuminate that concern, it would probably be helpful. If nothing else, there needs to be a note about it in the Standard to alert implementers and users.
On Mar 20, 2008, at 12:02 PM, Lars Hansen wrote:
//@line 123 "awesomeLib.js" throw Error("ow");
The error's line number is 123, file is "awesomeLib.js". We have some bits in there like a limit on the filename length (1024) and a cap on the line length (10x our "natural" line length, I think); eminently negotiable.
OK. We would need to accomodate other input sources than files at a minimum, maybe an optional string at the end (the file name could be optional too).
The filename is optional, defaults to "".
You could (absent security concerns) subsume filename under URL or
URI. "-" is an old Unix convention meaning stdin. What other input
sources did you have in mind?
I'm not sure we turned it on for content, because of spoofing concerns, but I'm pretty sure we use it for our chrome.
If you could dig up a discussion thread or actual person to illuminate that concern, it would probably be helpful.
/me raises hand
See bugzilla.mozilla.org/show_bug.cgi?id=243359 for the
history, which includes the inevitable "sometimes I want the revised
source coords, sometimes you want the originals" perplex.
On Tue, Mar 18, 2008 at 12:05 PM, Lars Hansen <lhansen at adobe.com> wrote:
-----Original Message----- From: Garrett Smith [mailto:dhtmlkitchen at gmail.com] Sent: 18. mars 2008 11:57 To: Lars Hansen Cc: es4-discuss Discuss Subject: Re: ES4 draft: Error classes
On Mon, Mar 17, 2008 at 12:11 PM, Lars Hansen <lhansen at adobe.com> wrote:
(Didn't know who to follow up to so lamely following up to myself.)
What does this have to do with getting a stack trace?
I see.
var color = el.style.color
where el is null, a ReferenceError would be thrown. It would be useful to have a backwards-compatible way to get that stack trace. How can - assert - be detected?
What about libraries that already have an assert() function?
"assert"in window?
Garrett
-----Original Message----- From: Garrett Smith [mailto:dhtmlkitchen at gmail.com] Sent: 20. mars 2008 21:40 To: Lars Hansen Cc: es4-discuss Discuss Subject: Re: ES4 draft: Error classes
On Tue, Mar 18, 2008 at 12:05 PM, Lars Hansen <lhansen at adobe.com> wrote:
-----Original Message----- From: Garrett Smith [mailto:dhtmlkitchen at gmail.com] > Sent: 18. mars 2008 11:57 > To: Lars Hansen > Cc: es4-discuss Discuss > Subject: Re: ES4 draft: Error classes >
On Mon, Mar 17, 2008 at 12:11 PM, Lars Hansen <lhansen at adobe.com> wrote:
(Didn't know who to follow up to so lamely following up to myself.)
What does this have to do with getting a stack trace?
I see.
var color = el.style.color
where el is null, a ReferenceError would be thrown. It would be useful to have a backwards-compatible way to get that stack trace.
How is the mechanism not backward compatible? Either context and backTrace are available on the error object, or they are not, but this particular aspect does not depend on whether 'assert' is available or not.
How can - assert - be detected?
Since 'assert' is a new keyword it would only have special meaning in scripts that are loaded with "application/ecmascript;version=4", so detection would in that sense be implicit.
Since we're just hacking among friends then the following works in both ES3 and ES4, I believe, it makes sure that 'assert' is defined globally and throws an error if the condition is false, and it uses the ES4 assert if available:
if (window.ECMASCRIPT_VERSION >= 4) window.assert = global.eval("function (x) { assert(x) }", 4); else window.assert = function (x) { if (!x) throw new Error("ASSERTION FAILED") }
ES3 code and ES4 code would both just do eg
assert(limit >= 0);
Clearly the optional second parameter can't be accomodated with the same semantics as in ES4.
What about libraries that already have an assert() function?
They would presumably be loaded in the ES3 syntax compatibility mode and there would not be a conflict.
"assert"in window?
Ditto (counterexamples or more elaborate questions welcome).
-----Original Message----- From: Brendan Eich [mailto:brendan at mozilla.org] Sent: 20. mars 2008 15:31 To: Lars Hansen Cc: Mike Shaver; es4-discuss Discuss; P T Withington Subject: Re: ES4 draft: Error classes
On Mar 20, 2008, at 12:02 PM, Lars Hansen wrote:
//@line 123 "awesomeLib.js" throw Error("ow");
The error's line number is 123, file is "awesomeLib.js". We have some bits in there like a limit on the filename length (1024) and a cap on the line length (10x our "natural" line length,
I
think); eminently negotiable.
OK. We would need to accomodate other input sources than files at a
minimum, maybe an optional string at the end (the file name could be
optional too).
The filename is optional, defaults to "".
You could (absent security concerns) subsume filename under URL or URI. "-" is an old Unix convention meaning stdin. What other input sources did you have in mind?
Considering multiple execution environments, the list looks at least like this:
- files
- inline scripts
- event handlers
- linked scripts (URLs I guess)
- javascript: URLs
- "eval" text
- "new Function" text
- stdin and similar streams
I don't know how much detail is useful nor how much can really be revealed without becoming insecure; clearly depends on the environment.
I'm not sure we turned it on for content, because of spoofing concerns, but I'm pretty sure we use it for our chrome.
If you could dig up a discussion thread or actual person to
illuminate
that concern, it would probably be helpful.
/me raises hand
See bugzilla.mozilla.org/show_bug.cgi?id=243359 for the history, which includes the inevitable "sometimes I want the revised source coords, sometimes you want the originals" perplex.
Yeah, that one was bound to come up.
Thanks for the reference, will read it and ponder the options.
The error classes are utterly boring except for the wrinkle that the predefined subclasses of Error -- EvalError, RangeError, and so on -- all have a [[Class]] that is "Error", not their natural class name. Anyhow, the draft is enclosed.
Unlike the ES3 spec, I've expanded the subclasses of Error into individual sections, because I always felt like I had to do a mental instantiation of what I was reading when I was reading these sections in the ES3 spec. (On the other hand, the spec is maybe a percent larger with the expansion.)