Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!wuarchive!mit-eddie!bloom-beacon!eru!hagbard!sunic!liuida!mip
From: mip@IDA.LiU.SE (Mikael Patel)
Newsgroups: comp.lang.forth
Subject: Re: CATCH and THROW
Message-ID: <1990Sep18.083102.8991@ida.liu.se>
Date: 18 Sep 90 08:31:02 GMT
References: <9009172348.AA19506@ucbvax.Berkeley.EDU>
Sender: news@ida.liu.se (News Subsystem)
Organization: CIS Dept, Univ of Linkoping, Sweden
Lines: 99

In article <9009172348.AA19506@ucbvax.Berkeley.EDU> wmb%MITCH.ENG.SUN.COM@SCFVM.GSFC.NASA.GOV writes:
>In the approach described above, the "guarded" code is the remainder of
>the definition which contains the CATCH1 , i.e.:
>
>        : xxx
>            ...
>            CATCH1
>            <guarded code>
>        ;
>

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.

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.

Just to present yet an alternative form of exception handling, this
this the form in TILE forth:

	: xxx ( a1..an -- ...)
		<guarded code>
	exception> ( a1..an e -- ..)
		<exception code>
	;

The principle words for defining exceptions (user level) and activating
them are:

	exception <name> ( -- e)
		Creates an exception name which when used will 
		push its reference onto the parameter stack.

	raise ( e -- )
		Activates the latest exceptions block with the
		given exception. Stacks are restore accordingly.

Typically a set of exceptions are defined to catch low level signals
such as arithmetic and addressing errors. An example of the usage 
would be a source module for handling stacks (the typical academia
example :-)

	exception stack-full ( -- e)
	exception stack-empty ( -- e)

	: push ( x s -- )
		<check for full stack> 
		if stack-full raise then
		<push element onto stack>
	;

	: pop ( s -- x)
		<check for empty stack> 
		if stack-empty raise then
		<pop element of stack>
	;

And usage of the stack:

	10 STACK aStack ( -- s)

	: add ( -- )
		aStack pop aStack pop + aStack push
	  exception> ( e -- )
		case
		  stack-full of <exception handling> endof
		  stack-empty of <exception handling endof
		  raise
		endcase
	;

The 'raise' in the 'case' block will cause the exception to be sent
to the next exception handling frame.

The form above is very close to that in Ada and Eiffel and (now to
the important part) it does not say anything about implementation!

One of the most important aspects of exceptions is that it allows
us to separate the 'normal' action (algorithm) from the 'error'
case. Calls to operating systems often return error code which
forces us to mix the normal and error case of an algorithm.

>In my opinion, Forth has too many different kinds of closures already.
>

Closures are not that bad. They give use a method of abstraction.
If Forth had a code block definition (like for instance PostScript)
closures would not be needed. But...forth is forth!

>Finally, it is unclear whether or not CATCH1 works in interpret state,
>due to its unbalanced return stack effect.

Oops! implementation detail again. But why use exception in interpret
state after all. Do you have an example of this, Mitch?

Mikael Patel, mip@ida.liu.se