Re: No exceptions?

From: paul c <toledobythesea_at_oohay.ac>
Date: Fri, 30 Jun 2006 20:14:34 GMT
Message-ID: <KCfpg.112543$IK3.51990@pd7tw1no>

Bob Badour wrote:

> Jonathan Leffler wrote:
> 

>> paul c wrote:
>>
>>> Bob Badour wrote:
>>> ...
>>>
>>>> The way to avoid exceptions is to treat them as compile-time errors.
>>>
>>> I take it you really mean "ONE way to avoid exceptions ...". For one
>>> thing, I am interested in being able to express "x join y" in advance
>>> of defining a header for "x" (and I would like to evaluate it as well
>>> if that is logically possible!).
>>
>> Don't forget the converse problem - there was a relation y at compile
>> time that was removed before runtime; there's no way to generate a
>> compile time exception for the unexceptionable, but there are not many
>> ways of avoiding a runtime exception if the compile time y had defined
>> attributes (was not a synonym of DEE or DUM). Obviously, you could
>> reinterpret the entire program in the light of what you find at
>> runtime, but then why bother with the compilation in the first place?
>> Even within a single program, you could have a relation y available
>> when it is first interpreted that is dropped by the time the statement
>> referencing it is executed. So, some runtime exceptions are nigh-on
>> unavoidable, I think.

> 
> As soon as one drops y, whatever references it must either be dropped or 
> become unusable. Thus, as soon as one compiles a statement that 
> references any such resource, one would get a compile-time error. 
> Instead of generating a compile-time error when compiling some program, 
> one would get a compile time error when one tries to invoke the program.

Thanks for the important examples - I think they are leading into some of the operational exceptions that I was hoping would come later since I'm still not sure if the 'synonym' idea violates for example, TTM's logical underpinnings.

I think many products go to elaborate lengths and introduce arbitrary concepts to handle such cases, at least some of them try to prevent catalogue updates in a transaction (Jim Gray described a logical '2-phase' protocol for intension locks many years ago and I've seen it implemented and I've seen the complications that seem never to end due to the intricacy, for example a reversal of Jonathan's converse problem, a sequential transaction that references y and then deletes y's definition - what should happen if the reference is then referred to again? - when are such updates 'committed'?, and so forth. However, I think Gray's great insight was in how he explained so clearly the all-or-nothingness of transactions).

When all is said and done, I favour an application by application approach to program and transaction boundaries and would rather that the internal interpreter or evaluator not take such decisions, ie., the appl'n designer decides what a transaction is, not the system. For me, lock managers are just a short-cut, a troublesome one too, for the programmer to avoid having to re-iterate all the assertions that some action depends on, ie., that a definition of a relation exist in the catalog at the time the relation is mentioned. How practical this is I don't know for sure and it seems to require some replacement concept, such as a notion of 'before' and 'after' relations, or 'deltas'. Part and parcel of this for me is eliminating any notion of sequential statement order as well as mutable variables because I'd *like* to get the same result no matter which order the statements are evaluated. I think this would mean a two-pass evaluator, analogous to reading a book - you don't really understand the beginning until you've got to the end.

Without a specification or working example, I'm sure this looks like hand-waving, so I'll stop for now.

p Received on Fri Jun 30 2006 - 15:14:34 CDT