[Isolate-interest] checked vs. unchecked exceptions

[Pete Soper]

Godmar Back wrote:
>>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.)

I'm going to take your use of "crash" here as a program failure caused 
by a logic error. I think this tends to get weeded out as an application 
moves from development to deployment. In case you meant "crash" like 
"the runtime let me down!", here's a rant.

Some day we'll get out of the habit of assuming common language runtime 
systems explode without warning. Some day we'll trust the {Java,C#,*} 
runtime environments like we trust lib{c,m} or their non-Unixen 
equivalents now. Until that day comes a Link.{send,receive} could be 
wrapped with try/catch where the app developer knows what to do for the 
exceptional case. I contend that developers want to trust their tools 
and if links are to be a tool they have to be trusted at the most 
fundamental level. I'll leave out a story about when I worked for IBM in 
a machine shop and encountered a master machinist who didn't know 
whether I was from planet Earth or not (but he knew what good tools look 
like!!)

-Pete

> 
>  - 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.
>>
> 
> _______________________________________________
> Isolate-interest mailing list
> Isolate-interest@altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/isolate-interest
>