Re: No exceptions?
Date: Fri, 30 Jun 2006 20:14:34 GMT
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 - 22:14:34 CEST