Exception handling

Overview

The .NET programming languages provide built-in support for exception handling, which allows the program to detect and recover from errors during execution.

In managed code, execution cannot continue in the same thread after an unhandled exception. The thread terminates, and if it is the program thread, the program itself terminates. To avoid this, accurate exception handling should be used.

The FlexPendant SDK provides several exception classes, which are used when errors occur. If the operation is rejected by the controller safety access restriction mechanism, for example, a RejectException is thrown.

If an unhandled exception occurs the application crashes and TAF displays a gray message on the FlexPendant. After confirmation the FlexPendant will restart. To avoid this you should make sure that any potential error situations are dealt with properly by your code.

The message that you get when an unhandled error situation occurs may look like this. Do NOT contact ABB, but fix the error handling of your application.

Note
For more information on how the exception classes of the FlexPendant SDK work, see Reference Manual FlexPendant SDK. Also see Reliability to get more detailed information about exception handling for the FlexPendant platform.

Try-catch-finally

Exceptions are handled in try - catch (-finally) blocks, which execute outside the normal flow of control.

The try block wraps one or several statements to be executed. If an exception occurs within this block, execution jumps to the catch block, which handles the exception.

The finally block is executed when the Try block is exited, no matter if an exception has occurred and been handled. It is used to clean up system or controller resources.

If you do not know what exceptions to expect or how to handle them, they can be caught and nothing need to be performed. This, however, may result in difficult error tracing, as exceptions include information on what caused the problem. Therefore, try at least to display the exception message, either by using a message box or the types Debug or Trace. For more information, see Debug output and Trace and Debug.

Typecasting

When typecasting Signal or RapidData values, for example, there is a potential risk of typecast exceptions. To avoid this you can check the object using the is operator for both value and reference types:

Copy

if (aRapidData.Value is Num)
{
Num aNum = (Num) aRapidData.Value;
....
}

Copy

If TypeOf aRapidData.Value Is Num Then
Dim aNum As Num = DirectCast(aRapidData.Value, Num)
.....

In C# it is also possible to use the as operator for reference types. A null value is returned if the type is not the expected one:

Copy

DigitalSignal di = this.aController.IOSystem.GetSignal(“UserSig”) as DigitalSignal;
if (di == null)
{
MessageBox.Show(this, null, “Wrong type”);
}

.NET Best Practices

The .NET Framework Developer's Guide presents the following best practices for exception handling:

Know when to set up a try/catch block. For example, it may be a better idea to programmatically check for a condition that is likely to occur without using exception handling. For errors which occur routinely this is recommended, as exceptions take longer to handle.
Use exception handling to catch unexpected errors. If the event is truly exceptional and is an error (such as an unexpected end-of-file), exception handling is the better choice as less code is executed in the normal case. Always order exceptions in catch blocks from the most specific to the least specific. This technique handles the specific exception before it is passed to a more general catch block.