In article
<3a3113f4-8db9-451e-9809-768277b15ebc@[EMAIL PROTECTED]
>,
Bruce McFarling <agila61@[EMAIL PROTECTED]
> wrote:
>On Mar 12, 6:43 pm, Albert van der Horst <alb...@[EMAIL PROTECTED]
>
>wrote:
>> <m_l...@[EMAIL PROTECTED]
> wrote:
>> >Maybe, something like
>> >: myerror ?DUP IF . ABORT THEN ;
>> >?
>
>> : ?ERROR SWAP IF ( optionally store information) THROW ELSE DROP THEN
;
>
>(1) Obviously this is after the warning string has been show ... there
>is nothing to swap.
I see, I overlooked the .
So it should have been
: ?ERROR ?DUP IF ( store information) THROW THEN ;
The idea is that information is not shown at this point yet.
The error can still be caught and cause no output. If the exception
leads to a message to the end user the information stored can be put
to good use.
That is the difference with a throw.
For example you could have an exception "root of negative number"
that sometimes is caught and causes an application to switch
to using complex numbers. This is not for the square root itself
to decide, nor do you want spurious messages.
>
>(2) Not requiring THROW to be present but able to using THROW if it is
>available and the configuration file asks for it, is the primary
>design objective.
>
>If THROW was assumed to always be present and always be desired, .Nicl-
>err would be:
>
>: .Nicl-err ( throw# ca u ) {.Nicl-warn} EXECUTE THROW ;
Phrased otherwise :
if {.Nicl-warn} at this point unconditionally and direct outputs
information, one of the advantages of THROW would be lost.
The alternative is not hard. It could store a string somewhere.
Then a f.p. application is started with an overall catch.
At that point the exception is confirmed as a problem and the
string printed.
Note that one string buffer is sufficient.
(Flash! I've got to improve ABORT" in this way.)
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@[EMAIL PROTECTED]
&=n http://home.hccnet.nl/a.w.m.van.der.horst
|
