ES4 draft: Error classes

Lars Hansen lhansen at
Tue Mar 18 06:59:43 PDT 2008

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


> Michael
> ----------------------------------------------
> -----Original Message-----
> From: es4-discuss-bounces at 
> [mailto:es4-discuss-bounces at] On Behalf Of Lars Hansen
> Sent: Monday, March 17, 2008 12:12 PM
> To: es4-discuss Discuss
> Subject: RE: ES4 draft: Error classes
> (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.
>   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.
> --lars
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss at

More information about the Es4-discuss mailing list