Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Re: Reading empty directories via FTP error

From: rotenca:telvia:it at: 14-Nov-2003 12:40

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