[<<][packetforth][>>][..]
Mon Nov 13 19:10:01 EST 2006

weird bug in console interpreter

any error that's throw from within the console interpreter gives
something like this:

> e_undef throw
<string>:1: e_type: invalid argument type
> .bt
<string>:1: e_type: invalid argument type 
error:	#<error:e_type>
xt:	#<xt:string:=>
DS: <2> #<undef> #<error:e_undef> 
RS: <2> ->#<xt:lit> ->#<xt:rdrop>

that's on first run. on subsequent runs it's in <xt:string:+>, so the
error is probably stale.

ok. got it. stale error message: now run clear before i'm interested
in an error message. maybe i'm getting carried away, but it might
actually be possible to fix
- exception handling (throw)
- backtrace handling
- error reporting

exceptions work fine, but the error reporting and backtrace mechanism
are a pain. what's needed is something that goes like:

mark
	do stuff
if something went wrong, get the backtrace and error message


let's separate 2 cases

* low level error occurs, and we want to know the entire backtrace up
  to the user or file command that eventualle led to the error.

* low level error occurs, we want to really recover from it.

most of the time: throw/catch are used to restore global state = keep
dynamic binding consistent. what i'm interested in is a deep stack
trace where all the states are saved.

i'm talking out of my ass. this is way too complicated.

maybe i need an explicit 'dynamic-wind'.  now, dynamic wind is really
'abort' with shielding of the return stack. the functionality provided
is exactly that: provide a consistent exit point, and make sure the
return stack cannot be messed up.

now, backtraces don't make much sense outside these contexts, since an
RS is swapped, anything can happen. so i guess my semantics of
'clear-error' is not really so bad: recover will clean up the stacks,
but won't actually delete any data. clear-error will.



[Reply][About]
[<<][packetforth][>>][..]