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: 15-Nov-2003 0:43

> See in get-cur-dir: > > net-error reform ["Server error:" port/scheme cd]
By the way, get-cur-dir is an anomaly too - it is missing a net-log of the stimulus and of the server's actual response.
> 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
I might cry now. Authors of robust apps should take note of this last point. In fact it deserves an article all by itself.
> These are two solutions: > > >> error? try [catch[net-error ""]] > == true > >> error? catch[throw-on-error [net-error ""]] > == true
Oh good - I'll stop crying. I like the first one because I don't need to know what is being evaluated in the innermost levels.
> > 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.
But doesn't your: error? try [catch[ something ]] solve this generally?
> Carl S. says something like "let the error throw itself" about 1.2.10 > net-error, i do not understand what exactly he means.
I assume it means that: make error! "whatever" will automatically bubble up to whatever is interested in catching it - without requiring a throw. By the way, where does he say this?
> 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.
Yeah I wondered about that too. As you have demonstrated a Throw of an error! might bypass a Try, but I think everyone will probably see it if it does. It may cause grief however. If there are extra Catch lying left around after Throw has been removed - it probably will not hurt.
> 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.
I noticed that too - I deferred thinking about it while concentrating on the other things. I agree with you, I think they should be consistent. Testing for success here is probably better than trying to test for failure but missing some cases (like 4xx errors).
> > REBOL parses the directory list returned by LIST - what if the Parse
itself
> > fails because the parse rules are not appropriate for the listing?
...
> The problem in your answer is that the parsing of files is done only after > NLIST.
But NLST was broken (and not pretty) - so I consider logic relating to it suspect as well. I haven't, checked but it should be simple enough to parse the files directly after LIST and again after any NLST that occurs.
> 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. :-)
That is a good step. But maybe there will be a server response to LIST in the future that the parse rules will not be ready for because none of us has seen it yet. A really good step would be to raise an error when it fails (if we are not going to retry again with NLST). I mean, code that does not give you any information one thing - getting the wrong information worries me greatly. Regards, Brett