Best practice to catch FtpException

Question

Is it a good idea to catch the FtpExceptions that get thrown on the reply code?
Can one reply code only be linked with one error type?

If not, what is the best practice to seperate them?

Currently I check for the message (string), but in retrospect this seems a bit fishy.
What if at some point you guys detect a spelling error or something and fix it..
That would break my error catching.

Boris

Answer 1

You can't rely on the error text - it varies between FTP servers, as does the error code.

All you really know when an FTPException is thrown is that the server sent back a reply code saying something was wrong with the preceding command or the server's ability to carry it out.

Answer 2

Hmm,

What if I do a connection.Synchronise(...).
If that throws an error, I presume the EDT library does some error throwing based on the commands it was executing at that particular moment, right?
These should be pretty concistant, not? How do I best catch those?

Boris

Answer 3

If you get an FTPException, there was a server problem - invalid reply code. An IOException is what you'd expect - a network or file access problem.

Answer 4

Unfortunately, there seems to be no easy way to "globally" catch FTP exceptions. If there isn't I haven't found it yet. FTPControlSocket.SendCommand is virtual but I don't believe there is any way to hook the instantiation of the FTPControlSocket control property within in FTPClient and supply your own descendant of FTPControlSocket which implements exception handling as follows:

public override FTPReply SendCommand(
{
try
{
base.SendCommand()
}
catch(...)
{
}
}

IMO, the construction of FTPControlSocket within FTPClient should be virtual and allow for descendant classed to be used.

Currently, it seems that the only thing you can do is try to catch exceptions on every method call you make on FTPClient.
I have a situation where the FTP client connection is very flakey and can fail on any call so adding exception handling was a mess. I finally gave up on that approach and not I use a tolerance for the number of failures that have occurred within a certain interval which is handled entirely outside of the FTPClient (unfortunately).

Answer 5

Yes, you should be catching FTPException and IOException for every remote call of FTPClient.

Answer 6

Yes, you should be catching FTPException and IOException for every remote call of FTPClient.

Would you care to expand as to the reasoning behind this? Have you tried using FTPClient against a connection that has a tendency to fail? It quickly turns into a mess with exception handling code all over the place.

What you're saying here is that there is no alternative.

Answer 7

You might need to post some code to let us know what you mean.

FTPClient is not that different to the Socket class - a higher level Socket basically. Socket can throw a variety of exceptions for every method call.

I don't quite understand why you wouldn't want exceptions thrown when a method invocation fails. Or how using FTPClient with exceptions thrown for each method call is any more problematic than using Socket directly.

Answer 8

We'll do, I'll put something together to make this more clear.

Thanks!