[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
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.
> 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
errors
> already catched, else we'll use an invalid port.
Hmm.
> The same happened to me about previously working commands. But it is not
easy
> 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
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.
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.
