- From: Oliver Hunt <oliver@apple.com>
- Date: Mon, 04 Feb 2013 14:44:37 -0800
- To: Garrett Smith <dhtmlkitchen@gmail.com>
- Cc: whatwg@lists.whatwg.org, nathan.f77@gmail.com
On Feb 4, 2013, at 2:40 PM, Garrett Smith <dhtmlkitchen@gmail.com> wrote: >>> That's fair enough. Though not all exceptions are Errors -- DOMException >>> currently isn't, though I think some people want it to somehow inherit >>> from >>> Error. >>> > Why not? That's something lost in the mists of time, however just asking it w.r.t DOMException misses the point that any value in js can be thrown - there's no requirement that it be an object, let alone a subtype of Error. > >>> >>> For example, some devs may be interested in the "Error" object's >>>> "name" property, which is already a part of the object today but is not >>>> provided to "window.onerror" callbacks. And again, if additional >>>> properties are added in the future, it's just more and more properties >>>> that >>>> may need to get incrementally added to the "window.onerror" invocation >>>> arguments list. For example, I proposed the addition of an "innerError" >>>> property (or some would call it "cause") for chaining errors and masking >>>> internal errors that consumers shouldn't see, instead providing a >>>> customer-facing message. >>>> >>> >>> Yeah. >>> > Yep. Pass an error object with a stack trace. That's tricky - what is your "stack trace"? You can very easily end up leaking private information across frames. --Oliver
Received on Monday, 4 February 2013 22:45:19 UTC