ES4 draft: Error classes

Michael Daumling mdaeumli at adobe.com
Sun Mar 9 03:31:18 PDT 2008


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: es4-discuss-bounces at mozilla.org
[mailto:es4-discuss-bounces at mozilla.org] 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: 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.

--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 at mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss
> 
_______________________________________________
Es4-discuss mailing list
Es4-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss



More information about the Es4-discuss mailing list