Kevin Reid: dump into design issues

Kevin Reid — Tue, 26 Oct 2010 22:02:22 GMT

dump into design issues

New page

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 [http://www.google.com/search?q=site:eros-os.org+sealed+exceptions 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.

—[[User:Kevin Reid|Kevin Reid]] 10:48, 13 April 2010 (CDT)

{{stub}}
[[Category:Unresolved design issues]]

Kevin Reid: add stub info

Kevin Reid — Tue, 13 Apr 2010 15:48:34 GMT

add stub info

←Older revision		Revision as of 15:48, 13 April 2010
Line 32:		Line 32:

	{{stub}}		{{stub}}
-	~~[[Category:Unresolved design issues]]~~

Sealed throw - Revision history

Kevin Reid: dump into design issues

Kevin Reid: add stub info