Hi Brett,
> > > As I understand it, Catch does not trap errors at all, yet the FTP
> protocol
> > > code has "error? catch" in multiple places through the code. As users
> we
> > > can wrap our FTP stuff in a Try or Attempt to protect ourselves, but
> still
> > > the FTP code may fall apart unreasonably early.
> >
> > Catch trap errors, but only throwed errors.
>
> I think that Catch catches Throws only.
Yes, thowed errors also.
See in get-cur-dir:
net-error reform ["Server error:" port/scheme cd]
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
These are two solutions:
>> error? try [catch[net-error ""]]
== true
>> error? catch[throw-on-error [net-error ""]]
== true
> 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.
Carl S. says something like "let the error throw itself" about 1.2.10
net-error, i do not understand what exactly he means.
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.
> > In the case of connections handling, we must detect every error, also
> errors
> > already catched, else we'll use an invalid port.
>
> Hmm.
Some port error for cached item are due to this.
> I'm not sure - but testing for multiline on every FTP command probably
> wouldn't hurt.
I agree.
> > I have many doubts about this. The doubts are:
> >
> > 1) why to use NLIST? some servers do not implement LIST?
> >
> > 2) If LIST is not implemented, the server should return an error, not an
> empty
> > list of files.
> >
> > 3) The NLIST command is not sent in the same mode as LIST. The directory
> name
> > is not sent, like is sent in LIST.
>
> Excellent points.
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.
> REBOL parses the directory list returned by LIST - what if the Parse itself
> fails because the parse rules are not appropriate for the listing?
> This might have been a good reason to use NLST which will only return
> filenames not attributes.
> So maybe the test for an empty file-list should have been a test to see that
> the parse of the directory listing actually worked? In this way if LIST
> returns nothing and parse of nothing is ok, then NLST does not happen, it
> will be only when LIST returns something we cannot decipher that NLST will
> be used.
The problem in your answer is that the parsing of files is done only after
NLIST.
Here the check is done only on the raw lines picked from the port:
file-list: make string! 2000
while [line: system/words/pick port/sub-port 1] [append file-list join
line "^/"]
close-the-port
answer- "ok"-to-the-server
if empty? file-list [
make-nlist
]
parse-the-list-of-files
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. :-)
---
Ciao
Romano
--
To unsubscribe from this list, just send an email to
[EMAIL PROTECTED] with unsubscribe as the subject.
