> -----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. --lars > > Michael > ---------------------------------------------- > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Lars T Hansen > Sent: Sunday, March 09, 2008 8:25 AM > To: Michael Daumling > Cc: Lars Hansen; Mike Shaver; es4-discuss Discuss > Subject: Re: ES4 draft: Error classes > > On 3/9/08, Michael Daumling <[EMAIL PROTECTED]> 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.) > > --lars > > > > > Michael > > ---------------------------------------------- > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] On Behalf Of Lars Hansen > > Sent: Friday, March 07, 2008 4:31 AM > > To: Mike Shaver; es4-discuss Discuss > > Subject: RE: ES4 draft: Error classes > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] 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 > > <[EMAIL PROTECTED]>: > > > > 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. > > > > --lars > > > > > > > > (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 > > > _______________________________________________ > > > Es4-discuss mailing list > > > Es4-discuss@mozilla.org > > > https://mail.mozilla.org/listinfo/es4-discuss > > > > > _______________________________________________ > > Es4-discuss mailing list > > Es4-discuss@mozilla.org > > https://mail.mozilla.org/listinfo/es4-discuss > > _______________________________________________ > > Es4-discuss mailing list > > Es4-discuss@mozilla.org > > https://mail.mozilla.org/listinfo/es4-discuss > > > _______________________________________________ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
