Hi Ed,
it looks, that you missed my advice on this.
<<Ed>>
...
>>>If Error? try [Fred: Print "See?"][Print "Whatever!"]
>>>
>See?
>Whatever!
>
Yes. But the value that I was trying to assign Fred was the error that
was to occur when I attempted my action.
More accurately, I have written a couple of daemons, that execute a
command that I pass to it as a parameter. I wanted the daemon to send
out an email if it could not execute the action it was assigned.
Something like this (where Action is the variable that holds the
statement to be executed:
If Error? Error: Try [ Do Action] [ Send Warning email ]
Realizing that Try is similar to Do, I even used:
If Error? Error: Try [ Action] [ Send Warning email ]
The first executed without issue, making me think that everything was
executing OK; it wasn't. The second gave me the "no value" error.
But this is why I'm confused: If try is to be used to help trap errors,
why does it care if a value is set or not? That's why I pointed out that
I got the error when issuing a "write" command. If anything needed to be
trapped, it was that. How else can I tell if a file is not there, or I
don't have access permission, or the file system is too full, etc?
<</Ed>>
<<L>>
the situation is simpler than you think. You can use:
if error? set/any 'error try action [send warning email]
Try doesn't care what is the result value. Your problem is, that if you use
an expression like (error: ...), the interpreter fires an error, if the
result of the (...) expression is of the UNSET! datatype. This means, that
the error occurs outside of the try block, which means, that TRY cannot trap
it.
<</L>>
<<Ed>>
...
The above statements, BTW, were taken (in form) from a REBOL manual.
They were text-book examples...
<</Ed>>
<<L>>
yes, there are some misleading informations in the documentation...
<</L>>
<<Ed>>
I suppose I could use that technique as part of my error trapping, the
question still remains: why? Error trapping should have to do with
trapping errors, not (just) return values.
<</Ed>>
<<L>>
you can, you just need to know how and why...
<</L>>
Cheers
-L
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
