[Isolate-interest] checked vs. unchecked exceptions

[Godmar Back]

>From what I remember, the decision to use checked or unchecked
exceptions should reflect, among other considerations, whether one
expects applications to ordinarily recover or not recover from the
exceptional situation.  (JLS 11.2)

Do we apply the same yardstick here?

If so, arguments could probably be made either way, but there's one
thing that strikes me: isolates are called isolates because they
provide isolation.  If there's no need for isolation, applications
won't be written to use isolates.  If there is a  need for isolation,
then fundamentally multi-isolate applications cannot make assumptions
about the current state of an isolate with which another isolate is
communicating via a link.  They simply don't know whether it's still
up or not.

This reasoning would be a strong argument in favor of checked
exceptions, since by definition/expectation multi-isolate applications
must handle link failures whenever they occur.  These link failures
are assumed to be caused by another isolate's crash as opposed to an
explicit close() (a problem in application logic) or failures in the
underlying communication system (the aggregrate failure you mention.)

 - Godmar

On Sun, 10 Oct 2004 19:42:30 -0400, Pete Soper <pete@soper.us> wrote:
> 
> Do you put try/catch around every use of "new?" I'll bet you don't,
> because you figure if an out of memory exception is thrown there is
> simply nothing to do anyway. You are relying on new to be reliable. I
> think we should rely on Sendable to be reliable too. The EG hasn't
> discussed this yet as we're all extremely busy with other work. Yes, an
> isolate representing a link endpoint closing that link is going to cause
> an uncoordinated send/receive operation at the other endpoint to fail.
> If that couldn't be accounted for by system design then try/catch could
> be used as a special case. What I'm exploring is whether the world will
> be a better place if Link send/receive do not define checked exceptions
> via "throws." This puts the burden on implementors and I think the
> analogy with heap is valid: a decent implementation won't throw out of
> memory until all kinds of things have happened to try to find available
> storage (e.g. two days ago I read a Hotspot team member discussing the
> possibility of the VM giving up some of its internal cached space as a
> last ditch tactic). Something similar can be done with Link so that a
> send/receive failure (failure, not "rug pulling exercise" via one end
> doing a close) is tantamount to system (aggregate) failure.
>