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: brett:codeconscious at: 14-Nov-2003 13:52

> > As I understand it, Catch does not trap errors at all, yet the FTP
> > code has "error? catch" in multiple places through the code. As users
> > can wrap our FTP stuff in a Try or Attempt to protect ourselves, but
> > the FTP code may fall apart unreasonably early. > > Catch trap errors, but only throwed errors.
I think that Catch catches Throws only.
> What errors are throwed in a protocol? > > All errors handled by the net-error helper. Here it is the source: > > net-error: func [info][throw make error! info]
Ah this is interesting. View 1.2.10 does not have the throw. I've only realised this by re-reading your email after I created ftp-error-handling patch (see other email on this thread). 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.
> Every function which handles ports has an hidden [catch] attribute, so
when That's interesting.
> In the case of connections handling, we must detect every error, also
> already catched, else we'll use an invalid port.
> The same happened to me about previously working commands. But it is not
> to replicate.
I finally found a way to replicate a problem - at least for myself - see other email.
> But it seems to me that there are other points of code where the multiline > refinement is not used. > > What say the RFC about multiline: every ftp command can be multiline?
I'm not sure - but testing for multiline on every FTP command probably wouldn't hurt.
> 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
> list of files. > > 3) The NLIST command is not sent in the same mode as LIST. The directory
> is not sent, like is sent in LIST.
Excellent points. 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.
> So i think that can exists other errors about NLIST code.
Quite possibly.
> You patched the connection problem but I think it can be not the only one.
Ouch :-) It took me ages to find that one. But that connection problem was because the code for it was completely missing. Regards, Brett.