|Top Previous Next|
FreeFlyer offers users the capability to catch errors as they occur by using a Try block. From this position, it is common to want to learn more about the error that was captured, including both the number of errors and their respective error messages. This information can then be communicated to an operator via a ConsoleWindow, external report, or other interface in order to better understand what is going on in your Mission Plan and how to approach fixing it.
The Diagnostics object is the root of the error diagnosing capability in FreeFlyer. Used in conjunction with the Try block as shown in the following examples, the Diagnostics object enables users to obtain key information on the errors that they capture, particularly the count of the error messages as well as the messages for those errors. The Diagnostics object cannot be instantiated in script, and all of its members are static methods and properties so that they're always available to all Mission Plans. The most commonly used application of the Diagnostics object will be with the Diagnostics.GetLastErrorMessages().
For users who want more control over the complete reporting of error details across a Mission Plan's execution, the Diagnostics object has static properties, Diagnostics.ErrorCount and Diagnostics.ErrorMessages, which enable control over how multiple errors aggregate. As multiple errors are captured within various Try blocks throughout a Mission Plan run, the ErrorCount property is incremented appropriately and the new error message is placed into ErrorMessages appropriately. The user is then able to handle these errors as they see fit from any point in the Mission Plan and then clear them once they're done using the Diagnostics.ClearErrorMessages() method.
Note: While it is possible to key off Mission Plan logic based on the text of a FreeFlyer error as reported by the Diagnostics object, this is not considered a best practice. The underlying String text of an error message is prone to change in future versions of FreeFlyer, which means that by using the text in an If statement, for example, the user could introduce breaking changes into their own Mission Plans when they upgrade.
Manually Reporting Errors and Warnings
In many Mission Plans, particularly those for operations, it is important to identify certain Mission Plan states by warnings or errors even if FreeFlyer itself is not in a warning or error state. A common example of this is having a Targeting loop report a recommendation for a maneuver and then for If statements with conditions based on the mission's science objectives reject the resulting parameters if not meeting said objectives. In FreeFlyer, this is achieved using the Diagnostics object as shown below.
Note: Reported errors using the Diagnostics.ReportErrorMessage() can themselves be captured by a Try block if reported as a recoverable error. The Mission Plan will stop execution and report the error even inside of a Try block if the error is set as unrecoverable.
•Diagnostics Properties and Methods