Re: read_mini, ^G returns Null_String

[Günter Milde <milde@xxxxxxxxxxxxxxxxxxxx>]

On Tue, Aug 12, 2003 at 06:24:04PM +0200, Klaus Schmid wrote:
> ...
> If read_mini -- or any other evaluation of code, e.g. expression or
> function --
> produces a recoverable error condition, the execution thread switches to the
> ERROR_BLOCK, and after execution of that -- provided _clear_error() is used
> and no return is used within the ERROR_BLOCK  -- the execution will
> resume _after_the_offending_code_.
> 
> In contrary, the documentation says: ... execution will resume
> _at_the_next_statement_ ...
> Needless to say, that I would like to improve the documentation about this.
> Supposed I am not completly wrong of course ;)

IMHO, the problem arises/vanishes with the definition of "the_next_statement"

Remember that SLang is a stack based language, i.e. it translates

s = fun(arg);

to (something like)

arg;     % push arg on stack
fun();   % use arg from stack, push result on stack
s = ();  % get result from stack and assign to s

One complex statement translates to 3 simple ones and the difference between
your findings and the documentation vanish.

> I think it gets obvious by this, that the information about what is returned
> (i.e. left on stack) in case of an error or cancel is of special interest
> when using ERROR_BLOCKS. 

This might become more clear, if you use (or think in) RPN.

> Second choice, I think, would be to use a
> general stack-cleanup procedure; maybe necessary, if we have a block
> with different potential code pieces, which may cause errors.

Stack cleanup will come with SLang 2, error handling is improvable indeed.

Finally an example from the new dabbrev:
Scan_Mark.buffer_name triggers an error instead of a buffer name, if the
buffer is killed:

   ERROR_BLOCK % for Scan_Mark.buffer_name in case of invalid mark
     {
	_clear_error;
	Scan_Mark = create_user_mark();
	whatbuf; % return a sensible result
     }
     
   sw2buf(Scan_Mark.buffer_name);


Günter

-- 
Milde at ife.et.tu-dresden.de

--------------------------
To unsubscribe send email to <jed-users-request@xxxxxxxxxxx> with
the word "unsubscribe" in the message body.
Need help? Email <jed-users-owner@xxxxxxxxxxx>.