Sealed throw

From Erights

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* throw()n 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)

This page is a stub; it should be expanded with more information. If doing so, check the original E web site and the mailing list archives for content which could be moved into this page.