Re: [twsocket] FTPCli error handling
Hello Francois, hope you liked your trip :) Arno's suggestion looks good and wouldn't break any existing code. Well, we'll have to somehow determine local code errors then. And not forget to clear the flag. But at least it will provide a way to deal with the problem. As far as I remember, you are the first to request the special handling for local error codes. Maybe the reason is that i'm developing a fully automated downloader requiring no or minimal user action. Of course interactive app could just throw an error message and let the user find a solution, but I need to distinguish occuring errors in order to perform appropriate actions. Or - maybe somebody experienced in FTPCli could advise me how to handle the case I described in initial message (error with code 550 occured). -- Anton -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] FTPCli error handling
AS Current manner of reporting local errors is to set code 550 with an explaining message AS and call TriggerRequestDone. But I find it very confusing: for example, when trying to AS GET some file or directory listing we could receive true FTP response 550 if the AS requested file doesn't exist (so we should give up) as well as ICS response if AS connection couldn't be established (so we should retry) or there was error creating local AS file stream (so we should check HDD free space). And there's no way to distinguish AS these cases (except checking FLastResponse string, but I consider it rather unconvenient). AS So I think something is needed to be done to differentiate local problems of remote ones. AS I'd prefer changing 550 code to some another value unused by FTP servers (maybe even AS over 600 to avoid intersections for sure) but the ICS policy is NOT BREAK existing AS code, so maybe some flag like FLocalErrorHappened: Boolean will solve the problem? AG If a workaround is needed then IMO a field FLastLocalError of type AG LongWord or Integer could receive a meaningful error code and a method AG GetLastLocalError could return and reset the value back to 0? AS So, what will be your decision? AS I wouldn't hurry you, but I have a buggy project based on old FTP components AS and wish to rebuild it with ICS. Arno's suggestion looks good and wouldn't break any existing code. It is probably not trivial to record the local error code everywhere in the code. The inital design was to produce an error code which is compatible with the RFC defining FTP protocol (3 digits error code, probably what you named true FTP response) so that any application has no need for special code to handle local errors. As far as I remember, you are the first to request the special handling for local error codes. -- francois.pie...@overbyte.be The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] FTPCli error handling
So, what will be your decision? I wouldn't hurry you, but I have a buggy project based on old FTP components and wish to rebuild it with ICS. Looking forward to your answer. -- Anton -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] FTPCli error handling
Have you tried calling GetLastError or WSAGetLastError ? I think it's unreliable because error can occur by exception not by Winsock or Windows error. Moreover, LastError-s could be overwritten by subsequent API calls by the moment OnRequestDone will be called. -- Anton -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] FTPCli error handling
Anton Sviridov wrote: unconvenient). So I think something is needed to be done to differentiate local problems of remote ones. I'd prefer changing 550 code to some another value unused by FTP servers (maybe even over 600 to avoid intersections for sure). but the ICS policy is NOT BREAK existing code, Yes, this is the policy, it has pros and cons. so maybe some flag like FLocalErrorHappened: Boolean will solve the problem? I haven't looked at the FTP-Client component for a long time. If a workaround is needed then IMO a field FLastLocalError of type LongWord or Integer could receive a meaningful error code and a method GetLastLocalError could return and reset the value back to 0? -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] FTPCli error handling
Hello Arno, If a workaround is needed then IMO a field FLastLocalError of type LongWord or Integer could receive a meaningful error code and a method GetLastLocalError could return and reset the value back to 0? Well, it's something. Though I'm still not sure what's the best way to deal with the issue. Any flag or value must be somehow cleared after reporting (though TriggerRequestDone seems to be a nice place for it). Maybe something like OnLocalError handler will work... unfortunately currently I have no idea of how to inject the workaround into the existing code properly. -- Anton -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] FTPCli error handling
Have you tried calling GetLastError or WSAGetLastError ? -- francois.pie...@overbyte.be The author of the freeware multi-tier middleware MidWare The author of the freeware Internet Component Suite (ICS) http://www.overbyte.be - Original Message - From: Anton Sviridov an...@rambler.ru To: twsocket@elists.org Sent: Thursday, April 29, 2010 2:20 PM Subject: [twsocket] FTPCli error handling Hello all, it's me again and again with a question about FTPCli. Current manner of reporting local errors is to set code 550 with an explaining message and call TriggerRequestDone. But I find it very confusing: for example, when trying to GET some file or directory listing we could receive true FTP response 550 if the requested file doesn't exist (so we should give up) as well as ICS response if connection couldn't be established (so we should retry) or there was error creating local file stream (so we should check HDD free space). And there's no way to distinguish these cases (except checking FLastResponse string, but I consider it rather unconvenient). So I think something is needed to be done to differentiate local problems of remote ones. I'd prefer changing 550 code to some another value unused by FTP servers (maybe even over 600 to avoid intersections for sure) but the ICS policy is NOT BREAK existing code, so maybe some flag like FLocalErrorHappened: Boolean will solve the problem? If you reject the idea please explain me how to deal with this response mess. -- Anton -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
