On Mar 12, 1:52 pm, m_l...@[EMAIL PROTECTED]
wrote:
> On Mar 12, 8:22 pm, Bruce McFarling <agil...@[EMAIL PROTECTED]
> wrote:
> > On Mar 12, 12:40 pm, m_l...@[EMAIL PROTECTED]
wrote:
> > VARIABLE Nicl-errorcode
> > : Nicl-err ( throw# ca u -- )
> > {.Nicl-warn} EXECUTE DUP Nicl-errcode ! ?DUP IF
> > {Nicl-err} EXECUTE
> > THEN
> > ;
> 0 S" abc" Nicl-err
> would clear Nicl-errorcode. If it's built into the system, I do not
> know if one will be able to examine Nicl-errorcode before it's
> cleared. (OTOH, it may be no problem in your design, I do not know.)
Yes, it could.
(1) It starts with
' ABORT VALUE {Nicl-err}
In that case ... if the interpretors working after you abort, you can
check the error code.
(2) It commonly will be upgraded to THROW
' THROW TO {Nicl-err}
.... in which case the Nicl-err seems to be redundant but harmless.
(3) Someone other than me ever uses the library oversight system
(probably a retro computer hobbyist) and decides to do "something
else".
.... in which case its on their head.
Actually, now that you raise the point, I'm inclined to overwrite the
err-code more often ... in .Nicl-err to write the err-code before the
call to the {.Nicl-warn} xt, and in .Nicl-warn to write 0 into the err-
code ... to let someone catch and correct problems silently if they
are willing to put in place a {.Nicl-warn} that checks the .Nicl-err
value to silence (or perhaps redirect to a log) a message for a
problem that they are handling.
|
