SDO11 — Exceptions defined should be explained in more details

Exceptions defined should be explained in more details to make it more understandable. Some new exceptions are deemed necessary and Exceptions thrown are not consistent.

- Exceptions should be explained in more details to make it more understandable. Their description must clearly state its purpose and exactly when they are raised. Example 1: The exception ‘NotAvailable’ described in section 2.3.2.1 p2-18 is not very clear and is confusing with the exception ‘SDONotExists’ (p2-17) which is raised when a client of an SDO cannot reach the target SDO. It is not clear when and who raises this exception. Is it raised when the SDO is accessible but the hardware device the SDO is representing is not accessible? If not then who raises this exception. Example 2: InvalidParameter is raised in operation setDeviceProfile(…) (section 2.3.4.1 p2-23) if the object which is specified by argument does not exist. Explanation should be given to specify what it means by ‘object does not exist’. Note it is described as such in many other operations.

• The specification defines four exceptions (section 2.3.2.1 p2-17). These exceptions do not seem to cover all the necessary exceptions that are required. For example, no exceptions are defined to indicate internal errors. Different exceptions are thrown depending upon the operation type. The following are examples where new exceptions may be necessary: Example 1: ‘InvalidParameter’ and ‘NotAvailable’ exceptions are thrown in operation getCurrentMonitoringStatus(). These exceptions does not however reflect any internal errors that can occur during the task execution period (eg. cannot get the variable where the requested data is stored). Example 2: duration of the subscription to monitor SDO properties is not defined yet. But if defined that the subscription duration can be limited (both minimum and maximum) then perhaps new exception is necessary. Example 3: getDeviceProfile (section 2.3.3 p2-19) returns null if DeviceProfile does not exist. It is better to raise some exception rather than to return null.

• The specification provides information on exceptions thrown by all operations. But they are not consistent, do not cover all necessary errors in some cases or not well described. All the exceptions thrown in all operations should be discussed in more detail to clarify if they fulfill their purpose in all expect. The following are some examples of described issue: Example 1: operation getID() (section 2.3.3 p2-18 point 1) throws exception InvalidParameter if the requested id of the SDO is null. InvalidParameter according to its definition is raised when a parameter(s) specified in an operation call is invalid (section 2.3.2.1 p 2-18). The definition of InvalidParameter does not describe that it is also raised when requested value is null. Example 2: It should also be noted that in some cases InvalidParameter is raised when the list is empty. This is not in consistent with other similar operation that does not throw this exception when the list is empty and also does not conform to the description of the exception ‘InvalidParameter’.