Path: utzoo!attcan!uunet!decwrl!ucbvax!MITCH.ENG.SUN.COM!wmb From: wmb@MITCH.ENG.SUN.COM (Mitch Bradley) Newsgroups: comp.lang.forth Subject: Re: CATCH and THROW Message-ID: <9009191309.AA25742@ucbvax.Berkeley.EDU> Date: 18 Sep 90 19:15:58 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Mitch Bradley Organization: The Internet Lines: 66 > As object-orientation, exception handling comes in many flavors and > abstraction levels. Depending on your opinion about what a standard > definition of a language should achieve the current words for exception > might be too low level and give "away" too much of implementation. In the case of exception handling, the obvious place to put the exception frames is on the return stack, and one must assume that many implementors would choose to put them there, if allowed. Since the Forth return stack is accessible to the programmer, one must include in the definition of the exception handling method some statement about its effects on the return stack. This could take the form of either a positive statement: Items placed on the return stack before a CATCH1 are accessible afterwards (probably implying that the implementor is not allowed to use the return stack for the exception frame). or a negative statement: Items placed on the return stack before a CATCH1 are NOT accessible afterwards (implying that the implementor may use the return stack for the exception frame at his discretion). One nice feature of the ANS CATCH / THROW is that it completely avoids this issue. The "guarded" code is an entire colon definition, separate from the definition that installs the exception handler. Thus, there is no question about return stack usage (because the return stack is only ever accessible to the programmer within the context of a single colon definition). > Details as where the exception frame is stored etc gives problems with > for instance Forth chips as these often have problems picking things > on the stacks. The ANS CATCH / THROW mechanism works just fine on Forth chips, because it doesn't require "picking" the return stack. THROW pops the return stack until the exception frame is exposes, then pops the frame. >> Finally, it is unclear whether or not CATCH1 works in interpret state, >> due to its unbalanced return stack effect. > Oops! implementation detail again. Like I said, the fact that CATCH1 *might* (and probably will, on most implementations) have a return stack effect means that its specification must account for the possibility. > But why use exception in interpret state after all. Do you have an > example of this, Mitch? The classic example is debugging. When debugging, it is a pain to have to remember that there are certain things that you can't just type in at the keyboard and have them work the same way that the work inside a colon definition. It is even more of a pain to *explain* to novices why certain things don't work. It is nicer if everything just works. As Forth "catches on" here at Sun, I find that teaching and support is becoming more and more critical to success. Right or wrong, people expect things to work the same when interpreted and when compiled, and they are confused and unhappy when the expection is violated. (The worst offender is ' vs. ['] ). Mitch Bradley, wmb@Eng.Sun.COM