ES4 draft: Error classes

Lars Hansen lhansen at adobe.com
Fri Mar 7 04:31:19 PST 2008


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



More information about the Es4-discuss mailing list