[cap-talk] small notes re: waterken

[Marc Stiegler]

Since Joe-E is a verifier, not a rewriter, what exactly do you do in
Joe-E to make those errors fatal?

For waterken, I've been trying to persuade tyler that Errors (as opposed
to Exceptions) should crash the server. Currently the server does
something more complicated that is quite hard to recover from.

--marcs

On Thu, 2011-03-03 at 17:33 +0000, David Wagner wrote:
> Raoul Duke  wrote:
> > * I still fear some arbitrary runtime exception or error in there
> > since there's no try-catch. So it seems like there are potential, even
> > if far-fetched situations, that could break the
> > checkpoint/transactional nature.
> 
> For what it's worth, I had the same reaction as I was reading this
> set of email messages, so you're not the only one...
> 
> Here is one good thing about Joe-E, which (I think) takes care of one case
> you might be worried about.  In Joe-E, all VirtualMachineErrors are fatal.
> That is important, because those errors could be thrown at any time,
> for unpredictable reasons.  Because Joe-E makes them fatal, I'd presume
> one does not need to worry about one of them happening in the middle of a
> transaction and causing state to be checkpointed in an inconsistent state.
> (This includes OutOfMemoryError and StackOverflowError.)
> 
> But your general point remains.  Exceptions can sometimes happen at
> unexpected places in Java code, and it would be easy to overlook that
> a particular piece of Java code can cause an exception to be thrown.
> There are some cases that might not jump out at your eye.  For example,
> when using generics, ClassCastExceptions can be thrown at places you
> might not expect, due to the existence of heap pollution.
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk