Sealed throw

This page needs to be written. Here's a recent summary from e-lang:

> Just the general issue of error messages leaking information. I'm a bit > concerned about ex.eStack showing the arguments too, though it's > certainly useful. eStack has enough information that you're utterly doomed. Unfortunately there isn't a design issue page for it on the wiki, but the solution is that *every* thrown exception object, or  equivalently exception object you get from a catch block, is sealed. Besides the debugging information, the throw-catch itself is  *dynamically scoped* and therefore does not follow capability semantics; so we seal the information so that the only information a  catch give is 'unexpected failure within'. Only that with debugging access can see either the message or the eStack. Of course the REPL will automatically do that. E-on-CL contains a partial implementation of these semantics. Unfortunately, there's no formal writeup of the whole thing that I  know of, but there's some discussion in the mailing list archives. If you'd like to help implement these semantics, please do -- it's one of the big security problems currently in E-on-Java for untrusted-code purposes, and one of the things that needs additional design work and experience with Real Applications which need to do things like logging errors. —Kevin Reid 10:48, 13 April 2010 (CDT)