On Tue, Jun 12, 2012 at 5:19 AM, Mark S. Miller <erig...@google.com> wrote: > On Tue, Jun 12, 2012 at 10:14 AM, Charles Kendrick > <char...@isomorphic.com> wrote: >> The only way I can see this working is if there is a way for a given >> piece of code to trap an error and ask some kind of (elevated >> privilege) logging system to provide diagnostic information that a >> (privileged) end user can see. > > I'm not sure what you mean by "trap to an error",
My actual words were "to trap an error" so that probably explains the confusion :) > but the rest of your > description seems close to how SES's console.log, console.warn, etc > work. They are endowed with access to the privileged getStack function > and use it to display stack traces on the console's output. See > http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/logger.js#28 > http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/logger.js#157 > http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/useHTMLLogger.js#116 Yes, this is the pattern I had in mind. This also means there would be no need to worry about exposing too much information in a stack trace. >> It also seems like, in addition to >> this, you should be able to get to stack information programmatically >> so long as you stay within your module or modules that have the same >> privilege. > > If we're talking about code with some privilege to see some stacks, > why not reify such privilege in a getStack function importable from > some @privileged module? I don't have an objection to this being treated as an import. >> This doesn't sound like something that could be reasonably >> standardized into ECMAScript in the near future, and, without all >> those pieces in place, it doesn't seem like ECMAScript should just >> disallow the ability to get stack traces. > > In this thread, we've already considered APIs other than ".stack". > Given anything else, why is getStack(err) is any worse than > introducing a novel property name? There's no problem with the API being changed to a getter method as opposed to error.stack / error.stackFrames. It would be a problem for access to a stack trace to require @import or other features that are not yet present in all mainstream browsers. If browser implementers cannot add this feature to engines which are basically only ES4/5, it's not going to be usable for mainstream code until 2019 or something - in reality, non-standard APIs will continue to be implemented and used. > Regarding near future, any such proposal -- whether ".stack", > getStack, or whatever -- has already missed the boat for ES6. getStack > certainly could be considered in an ES7 timeframe. Fortunately, these milestones have little to do with when features appear in browsers. And this is one of those features where it's valuable the moment it appears in just one browser. All we really need is clear consensus, so as to influence browser vendors' existing efforts in this area. >> Just to clarify, I prefer *some* of the ideas behind "use strict" and >> in fact we built a subset of "use strict" into our in-house tools long >> before JSLint existed. >> >> But if it's going to impose a security boundary between my own methods >> and reduce the utility of stack traces which are sometimes the only >> thing you have to go on.. no thank you. That seems to me to conflate >> useful error checking and security; there is overlap, but not 100% >> overlap by any means. > > How do getStack and @privileged reduce the utility of stack traces? They don't. The above discussion is about "use strict" and is not about SES. _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
