Issue 10707: DCPSError also becomes a 'runtime' exception (data-distribution-rtf) Source: PrismTech (Mr. Erik Hendriks, erik.hendriks(at)prismtech.com) Nature: Revision Severity: Summary: Problem: Currently the DCPSError is used in various operations to indicate an error occuring in DCPS, however it is implementation specific for which operations the DCPS is accessed. For example the getter of a simple attribute needs to access DCPS if the state of the object was not yet dereffed. And because it's up to the implementation to decide where to keep it management information, it also possible to get DCPS errors on operations which the specification does not define them. For example a refresh on a Selection or the get_objects on a CacheBase or ObjectHome may raise DCPSErrors in our implementation. To give a better flexibility we suggest to make the DCPSError exception runtime as well, especially since often such exceptions are not recoverable. In such cases that the exception IS recoverable we suggest introducing a specific exception for that case. For example introducing a timeout exception in the write operation of the CacheAccess to deal with the fact the DCPS DataWriter timed out, as that is recoverable, but an error code indicating the DataWriter is deleted is not recoverable. Solution: Replace (in section 3.2.1.1): Exceptions in DLRL will be mapped according to the default language mapping rules, except for the AlreadyDeleted exception. Since this exception can be raised on all methods and attributes (which is not possible to specify in IDL versions older than 3.0), it is not explicitly mentioned in the raise clause of each operation. Implementors may choose to map it onto an exception type that does not need to be caught explicitly, simplifying the DLRL code significantly. With: Exceptions in DLRL will be mapped according to the default language mapping rules, except for the AlreadyDeleted and DCPSError exceptions. Since these exception can be raised on all methods and attributes (which is not possible to specify in IDL versions older than 3.0), it is not explicitly mentioned in the raise clause of each operation. Implementors may choose to map it onto an exception type that does not need to be caught explicitly, simplifying the DLRL code significantly. Resolution: Revised Text: Actions taken: February 12, 2007: received issue Discussion: End of Annotations:===== iler: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 12 Feb 2007 17:08:39 -0500 To: issues@omg.org, data-distribution-rtf@omg.org From: Juergen Boldt Subject: issue 10707 -- DDS RTF issue X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org This is issue # 10707 From: "Erik Hendriks" DCPSError also becomes a 'runtime' exception Problem: Currently the DCPSError is used in various operations to indicate an error occuring in DCPS, however it is implementation specific for which operations the DCPS is accessed. For example the getter of a simple attribute needs to access DCPS if the state of the object was not yet dereffed. And because it's up to the implementation to decide where to keep it management information, it also possible to get DCPS errors on operations which the specification does not define them. For example a refresh on a Selection or the get_objects on a CacheBase or ObjectHome may raise DCPSErrors in our implementation. To give a better flexibility we suggest to make the DCPSError exception runtime as well, especially since often such exceptions are not recoverable. In such cases that the exception IS recoverable we suggest introducing a specific exception for that case. For example introducing a timeout exception in the write operation of the CacheAccess to deal with the fact the DCPS DataWriter timed out, as that is recoverable, but an error code indicating the DataWriter is deleted is not recoverable. Solution: Replace (in section 3.2.1.1): Exceptions in DLRL will be mapped according to the default language mapping rules, except for the AlreadyDeleted exception. Since this exception can be raised on all methods and attributes (which is not possible to specify in IDL versions older than 3.0), it is not explicitly mentioned in the raise clause of each operation. Implementors may choose to map it onto an exception type that does not need to be caught explicitly, simplifying the DLRL code significantly. With: Exceptions in DLRL will be mapped according to the default language mapping rules, except for the AlreadyDeleted and DCPSError exceptions. Since these exception can be raised on all methods and attributes (which is not possible to specify in IDL versions older than 3.0), it is not explicitly mentioned in the raise clause of each operation. Implementors may choose to map it onto an exception type that does not need to be caught explicitly, simplifying the DLRL code significantly. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org