EldoS | Feel safer!

Software components for data protection, secure storage and transfer

TEISimpleSSHClient.ExecuteCommand() -- no exceptions thrown?

Also by EldoS: BizCrypto
Components for BizTalk® and SQL Server® Integration Services that let you securely store and transfer information in your business automation solutions.
#24381
Posted: 03/30/2013 18:33:32
by Ken Ivanov (EldoS Corp.)

Michael,

That's all right - indeed it was quite easy to get lost among different replies and behaviours exposed by different versions of the library. We are sorry about the confusion.

Quote
The production version ExecuteCommand (now and any future ones) throws connection related exceptions, but once a connection is established, other errors (ie protocol errors) are reported via OnError only.

Yes, that's correct. In other words, if ExecuteCommand() throws no exceptions, it guarantees that the component has connected successfully to the server and launched the command. The further progress of the command can be analyzed with the help of OnError event and CommandCompleted property.

Quote
One last thing I would like to clear up on this thread, though, is the "division of errors" (my wording) reported via exception vs those reported via OnError.

The things differ depending on the exact component being used. Components shipped with SecureBlackbox can be divided into several logical layers; components from different layers use different exception reporting models. Transport components are generally divided into two layers:
(1) Higher-level synchronous components with built-in networking functions (TElSimpleSSHClient, TElSimpleSFTPClient);
(2) Lower-level asynchronous components that can be viewed as a sort of bricks from which higher-level components are constructed (TElSFTPClient, TElSSHClient, TElSSHTunnelList).

Most of the higher-level synchronous components, with fairly small amount of exceptions, always use exceptions model to report problems. In other words, if a method did not throw an exception, you can be sure that it has succeeded. At the same time, *in addition to throwing exceptions*, some components report protocol errors via the OnError event. The reason for operating this way (and not to report protocol errors via exceptions) is that in general case (a) it might be more than one protocol error leading to an exceptional situation and (b) the components may recover from certain protocol errors and still complete the requested operation successfully.

This way, when working with, say, TElSimpleSFTPClient's methods you can use a familiar try/catch clause to distinguish between successful and unsuccessful method calls. Yet, it is also a good idea to handle the OnError event for diagnostics purposes. For example, it would be much easier to find the root of the problem if you know the exact protocol errors that were reported just before the exception.

TElSimpleSSHClient.ExecuteCommand() is a rare exception method which does not throw exceptions if a problem occurs during command execution. This behaviour is intentional and has a goal of preserving the command output already obtained from the server.

So, to conclude:

Quote
My understanding is that all errors that prohibit establishing a successful connection are going to be reported via exception (for all the methods/components involved in this conversation). After that point, "protocol level" errors are not reported by exception, but only by OnError.

This statement is only valid for the TElSimpleSSHClient.ExecuteCommand() method.

Quote
Ultimately I need to know conclusively in my app whether or not an operation failed (at any point) and what I need to do to sense this; do I need to monitor both exceptions and OnError, or just exceptions?

It is desirable to monitor both, yet only exceptions should be used to distinguish between successful and unsuccessful calls. Errors reported through the OnError event should be traced down to simplify problem diagnostics.

In the particular case of the ExecuteCommand() method, CommandCompleted property should be used to track the success or failure of the operation.
#24401
Posted: 03/31/2013 17:39:28
by Michael Lovett (Standard support level)
Joined: 03/20/2013
Posts: 28

Awesome reply. Thanks so much.
#24402
Posted: 03/31/2013 17:40:16
by Michael Lovett (Standard support level)
Joined: 03/20/2013
Posts: 28

Quote
Michael Lovett wrote:
Awesome reply. Thanks so much.


Also, it would be awesome to see this kind of "Theory of Operations" insight in the help file :)

Reply

Statistics

Topic viewed 2878 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!