The recent thread on exception handling reminded me about another bit of work
we did in the Interval MediaTalk system to help primitive failures provide
useful information about _how_ they failed.

If you are going to have exceptions raised when a prim fails, it is nice to
think that there might be some way to explain _what_ failed. For example, if a
file renaming prim fails, what was the cause:-
	the given file does not exist
		it is locked
		it is not writable by user
	the replacment name is bad
		how? too long? bad chars?
	the operation failed
		why? the disk exploded? a meteorite strike on the power lines?
none of which are trivial to work out without careful, time consuming checking.
However, more often than not the underlying OS will give you some pretty good
idea if only you have a way to pass the info back to the VM/image.

What we did (freely copied from memories of a similar idea in VW) is to
automagically add a first 'hidden' temp to any method that calls a prim. Thus
the prim code can set this temp to anything it wants, normally a simple
integer, to indicate the problem ready for the backup code to check. The temp
name has a default but that can be overridden.

Obviously this requires a VM spin and an image that has the primitive calling
methods recompiled, plus all the prims with interesting failure modes need
altering. There is code to illustrate the basic changes in <http://sumeru.
stanford.EDU/tim/pooters/SqFiles/deltas/PrimErRet2.zip for anyone interested.




-- 
Useful random insult:- High relative humidity...  He's lost in a fog.
Tim Rowledge:  rowledge at interval.com (w)  +1 (650) 842-6110 (w)
 tim at sumeru.stanford.edu (h)  <http://sumeru.stanford.edu/tim>