> See in get-cur-dir:
>
> net-error reform ["Server error:" port/scheme cd]
By the way, get-cur-dir is an anomaly too - it is missing a net-log of the
stimulus and of the server's actual response.
> the error is thrown, so if you use try, the error by-pass your try:
>
> >> error? try [net-error ""]
> ** Throw Error: ** User Error:
> ** Near: throw make error! info
I might cry now. Authors of robust apps should take note of this last point.
In fact it deserves an article all by itself.
>
> These are two solutions:
>
> >> error? try [catch[net-error ""]]
> == true
> >> error? catch[throw-on-error [net-error ""]]
> == true
Oh good - I'll stop crying. I like the first one because I don't need to
know what is being evaluated in the innermost levels.
> > So without the throw I thought to myself "this ERROR? CATCH thing is
> > useless - I should replace the CATCH with a TRY". This is what the patch
> > file does.
>
> This is a thing to test. In the specific connections case, under 1.2.10
the
> catch is unuseful. But in other cases must be checked. The problem is that
can
> exists a thow-on-error somewhere, or some function attributes which change
the
> error behaviour when it is cupled with return.
But doesn't your:
error? try [catch[ something ]]
solve this generally?
> Carl S. says something like "let the error throw itself" about 1.2.10
> net-error, i do not understand what exactly he means.
I assume it means that:
make error! "whatever"
will automatically bubble up to whatever is interested in catching it -
without requiring a throw.
By the way, where does he say this?
> About the change in 1.2.10, i am not sure that all the existing protocols
> (third party also) are not affected by this change.
Yeah I wondered about that too. As you have demonstrated a Throw of an
error! might bypass a Try, but I think everyone will probably see it if it
does. It may cause grief however. If there are extra Catch lying left around
after Throw has been removed - it probably will not hurt.
> I have another point: why it tests only the "5", NLIST is like LIST, LIST
> waits a 2 class answer, the same should be for NLIST.
I noticed that too - I deferred thinking about it while concentrating on the
other things. I agree with you, I think they should be consistent. Testing
for success here is probably better than trying to test for failure but
missing some cases (like 4xx errors).
> > REBOL parses the directory list returned by LIST - what if the Parse
itself
> > fails because the parse rules are not appropriate for the listing?
...
> The problem in your answer is that the parsing of files is done only after
> NLIST.
But NLST was broken (and not pretty) - so I consider logic relating to it
suspect as well. I haven't, checked but it should be simple enough to parse
the files directly after LIST and again after any NLST that occurs.
> But your point opens another bug area of ftp: parse rules.
>
> They can fail also only on 1 item, not all (i had this experience some
time
> ago and the same says Carl Read on a recent mail).
>
> The solution here is to correct the bugs of parse rules. :-)
That is a good step. But maybe there will be a server response to LIST in
the future that the parse rules will not be ready for because none of us has
seen it yet.
A really good step would be to raise an error when it fails (if we are not
going to retry again with NLST).
I mean, code that does not give you any information one thing - getting the
wrong information worries me greatly.
Regards,
Brett
--
To unsubscribe from this list, just send an email to
[EMAIL PROTECTED] with unsubscribe as the subject.
