RE: ES4 draft: Error classes
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
--
-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
Re: ES4 draft: Error classes
On 09/03/2008, Michael Daumling [EMAIL PROTECTED] 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? -- David liorean Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
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
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?
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
thatline, 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
Re: ES4 draft: Error classes
On Sun, Mar 9, 2008 at 12:11 PM, Michael Daumling [EMAIL PROTECTED] 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 ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Error classes
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 https://bugzilla.mozilla.org/show_bug.cgi?id=307984 /be ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Error classes
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 [EMAIL PROTECTED] 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. -- David liorean Andersson ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: server-side ECMAScript 4?
Michael O'Brien-4 wrote: We will be using our ES4 implementation server side. Mainly for embedded uses, but it could apply more broadly. We have a server side page technology like ASP -- called ESP. ... we have had to add quite a bit of extra library code suitable for server side processing. What kind of server side were you interested in? Small Business Web Hosting including data base. Low development cost more important than maximum scalability. Emphasis on client ability to maintain website [after initial deployment] using lower-skilled people as much as possible, to lower lifetime costs. Sticking closely to mainstream software wherever possible, in hopes of marketing broadly to other web developers. Specifically, compatibility with Adobe tools for web designers; otherwise standards and open source. My current thinking is that the base server side infrastructure can be completely open source. I think there are enough open source pieces out there to pull that off. If so, could gather strong momentum that wouldn't be possible if not open source. Make revenue by customized add-ons on top of the open source base, combined with consulting services in utilizing the total solution. If your company identified a server-side base layer that it could make sense to you to open source, that would be a discussion of interest to me. Steve -- View this message in context: http://www.nabble.com/server-side-ECMAScript-4--tp15921812p15946653.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ES4 draft: Object
Brendan Eich wrote:
On Mar 8, 2008, at 1:16 PM, Yuh-Ruey Chen wrote:
But doesn't DontEnum still have to be there for ES3 objects? How else
would you prevent the enumeration of ES3 builtin methods, e.g.
Object.prototype.toString()? Or is there some more open namespace
magic
that I'm unware of?
ES3 code can't detect namespaces, so arguably shouldn't care if we
were to implement DontEnum using an open namespace. But this could be
a problem for mixed ES3 and ES4 scenarios where the ES4 code does
introspect via Name objects and is surprised to find ES3 objects
with qualified property names.
I'm talking about how the enumerability (or lack thereof) of
Object.prototype.* are determined. Or are prototype methods also not
enumerable by default like fixtures?
Let me get this straight. The rules of enumerability are:
1) If a property is a fixture, it's not enumerable. BTW, what exactly is
a fixture? Does this included ES3-style prototype methods? And would it
be possible to init a fixture to be enumerable?
2) If a property is not in the public namespace, it's not enumerable.
3) Otherwise, it is enumerable.
4) No hidden DontEnum attribute.
Are we trying to simplify this to the last three rules using some
namespace voodoo to handle the fixture rule? I'm confused.
Well, I think the only overlap is that public-in-class-context methods
(or any method really) default to be non-public in terms of
enumerability
Is that the right design?
dynamic class C {
public var fixture;
function C() { this.expando = 42; }
}
for (var i in new C)
intrinsic::print(i);
wouldn't you expect to see expando printed? Is it printed because
the default namespace for expando is the public-default one? I
believe it is not, in the current proposal and the RI. Rather, each
class or package gets a nonce-named public namespace, different from
every other such per-class or per-package public. IIRC package trumps
class -- classes within a package share the package's nonce-named
public namespace (Jeff, Lars, please correct me if I'm wrong).
I meant non-expando vars and methods defined within the class, whatever
the terminology is used (I see 'fixture' thrown around everywhere), are
not enumerable. So yes, expando should be printed. And the RI does print
it, so I'm not sure what you're talking about. Are you saying that each
property is defined in a class-specific public namespace, and
therefore does not get enumerated? I would say that expando properties
should be defined in the global public namespace, so that they would
be enumerated.
-Yuh-Ruey Chen
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
