When using LoadDer how are loading errors to be handled?

0 votes
asked Dec 8, 2015 by nevar (280 points)

When calling LoadDef on the certificate class it isn't clear how errors should be handled, and what they could possibly be.

Currently the help page for LoadDef does not give any indication how errors are passed back.

Is an exception thrown? If so how do I locate details on this through the help page?

(Also for a number of different calls. After writing this I found another instance where I needed to know how errors were reported. The instance was calling the ftp client ChangeDirectory).

Thanks.

Applies to: Rebex FTP/SSL

1 Answer

+1 vote
answered Dec 9, 2015 by Lukas Pokorny (93,630 points)
selected Dec 13, 2015 by nevar
 
Best answer

Unless stated otherwise, Rebex API methods raise exceptions to indicate errors and return successfully to indicate success.

LoadDer and other methods in Certificate and related classes usually throw CertificateException or CryptographicException on errors, although another exceptions are possible as well when appropriate (a non-existent file will lead to FileNotFoundException).

Ftp object mostly raises FtpException on errors that contains a Status and Response properties that often contain additional information. Other components (SFTP, Secure Mail, and so on) use the same approach.

commented Dec 9, 2015 by nevar (280 points)
Thanks for that Lukas. Is there a way to tell what potential exceptions are raised from a call into the rebex library? When displaying errors to user we prefer to be as detailed as possible.
commented Dec 10, 2015 by Lukas Pokorny (93,630 points)
.NET does not have enforced (checked) exceptions like Java, which makes this hard to tell exactly. In general, you should handle exceptions when you can actually do something about them. In addition to FtpException, Rebex FTP/SSL might throw TlsException (on errors related to TLS/SSL) or IOException (on filesystem access errors). Of course, ArgumentException, InvalidOperationException and ObjectDisposedException are possible when appropriate. Other than this, no other exceptions should be thrown by Rebex FTP/SSL (the low level API on Rebex.Common assembly might use other exceptions such as CertificateException or CryptographicException).
commented Dec 13, 2015 by nevar (280 points)
No worries. Thought this would be the case. Just means that every call is going to have a blanket catch statement which we have report as a user exception (e.g. the same as invalid credentials) as we don't have an definite list as to what each call throws. To make things more complete I would suggest adding a list of exceptions thrown and reasons as to why for each call within in the Rebex libraries. This will make implementations a great deal easier and more solid.
commented Dec 14, 2015 by Lukas Pokorny (93,630 points)
You are right - Rebex FTP/SSL documentation for exception can and should be improved and we will most likely do something about it in the future. However, we tried the suggested approach of one definite list per call (see (http://help.rebex.net/##RebexTotalPack.chm/Html/M_Rebex_IO_Compression_ZipArchive_Add_1_bb3a7a4f.htm) with Rebex ZIP and found out that it's far from perfect. Although it's nice to be able to easily determine which kind of exception each method throws, there are two major issues with this:

1) Having to separately write a set of catch clauses for each call just doesn't seem right. It's difficult, error-prone and hard to maintain.
2) .NET/C# doesn't have a concept of "checked" exception like Java does, which means that it's almost impossible to get the exception list right.

Instead, I would like to have a kind of "Handling Rebex FTP/SSL exceptions" article describing in detail what kinds of exceptions are thrown by what kinds of calls. That would make it possible to quickly write a set of several general-purpose try/catch blocks for different categories of API calls instead of having to hand-craft each call separately.
commented Dec 14, 2015 by nevar (280 points)
Sounds perfect. Thanks for response. Looking forward to which ever direction you take.
...