Re: No exceptions?
- From: paul c <toledobythesea@xxxxxxxx>
- 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
.
- References:
- No exceptions?
- From: paul c
- Re: No exceptions?
- From: Bob Badour
- Re: No exceptions?
- From: paul c
- Re: No exceptions?
- From: Jonathan Leffler
- Re: No exceptions?
- From: Bob Badour
- No exceptions?
- Prev by Date: Re: No exceptions?
- Previous by thread: Re: No exceptions?
- Next by thread: Re: No exceptions?
- Index(es):
Relevant Pages
|
