[REBOL] Re: Reading empty directories via FTP error
From: rotenca:telvia:it at: 14-Nov-2003 2:34
Hi Brett,
> > another problem of the ftp handler is error handling (see
> > http://www.rebol.net/list/list-msgs/32024.html)
>
> I see your point about the error handling code in the FTP protocol - it does
> not look robust to me.
In the connections case is robust.
In the other cases, tests must be done to see if it is needed (i do not know)
and if it is robust.
> 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.
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]
try this:
error? catch [throw net-error ""] ;==true
error? catch [throw-on-error [2 / 0]] ; == true
But if an inner catch prevents the throw and fires the error, it will not
reach our catch statement and we'll not able to catch the error.
A function with the [catch] attribute catches all throwed errors and then
return it without throwing it again.
error? catch [do func [[catch]][throw-on-error [2 / 0]]]
** Math Error: Attempt to divide by zero
** Where: throw-on-error
** Near: [throw-on-error [2 / 0]]
Every function which handles ports has an hidden [catch] attribute, so when
the protocol handler throws the error, they can catch it and show, in the near
error field, the user line.
In the case of connections handling, we must detect every error, also errors
already catched, else we'll use an invalid port.
> > > I tried briefly to replicate the problem but couldn't - I got a
> different
> > > error!
> >
> > What error?
>
> I think the FTP server was complaining about the directory not existing - I
> haven't traced the problem, but I did find that at some point I couldn't
> then do previously working commands.
The same happened to me about previously working commands. But it is not easy
to replicate.
> > I think that the initial Ashley error with empty dirs was due to a not
> > existing dir + cached ftp port.
>
> Ashley's 226 error was solved (see patch in REBOL library). Ashley also had
The multiline error. Ok for the patch.
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?
> the same error as Carl's (NLST) - which hopefully now is solved.
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.
So i think that can exists other errors about NLIST code.
You patched the connection problem but I think it can be not the only one.
> Ashley's
> third problem was a general one about having had an FTP error, FTP could
> become unusable for the rest of the session - which I think you have
> identified in your error handling comments.
This was the Ashley error I also had.
---
Ciao
Romano
