8.3 Error Handling

This section describes how the design of RAMI handles errors, and the types of errors that can occur.

8.3.1 FCM

When errors are detected, the function which detects the error should return as soon as possible, without modifying any global data (except locks). The errors for which this should occur are:

• NULL pointers being passed as arguments where not expected
• Inconsistent data, such as the length of a packet pointing past the data provided

[SRS Reference 4.4]

8.3.2 SAM

The only requirement for error handling in SAM is that the user shall be notified wherever possible if an error has occurred and the nature of the error. [SRS Reference 4.4]

SAM does this by the use of the ErrorHandler class. This class is responsible for creating and displaying an error or warning dialog box, displaying a given error message on that dialog box, and ensuring the user acknowledges the error (by greying out the widget which has created the instance of the ErrorHandler class) before any further action is undertaken. Any other class may import ErrorHandler if it needs the use of error messages being displayed to the user. For more details on ErrorHandler, see the documentation for the class (section 5.6) and the class general design 4.

Also, SAM makes use of exceptions to handle errors. SAM will use not only the built-in Python exceptions, but will also use an additional exception class, CustomError, which enables any class to raise a custom exception. When raising a custom exception, the class may pass any error string to CustomError (which may then be caught by another class and the error message displayed to the user). The class may also pass an argument to the exception allowing the receiving class to distiguish between errors and warnings. For more details on CustomError, see the documentation for the class (section 5.6) and the class general design 4.