[jira] Updated: (TUSCANY-578) Exceptions thrown by SDO runtime not the same as defined in the spec

["Brian Murray (JIRA)" <tu...@ws.apache.org>]

     [ https://issues.apache.org/jira/browse/TUSCANY-578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Murray updated TUSCANY-578:
---------------------------------

    Attachment: 578.patch
                578.zip

I have attached a test case (contained in 578.zip) that verifies each of the explicitly identified Exceptions in the spec.   I have also attached a patch for several of the issues that were identified using the test case.

There were some issues identified that I do not think can be corrected in a manner with small enough of an impact given the nature of the correction being made.  Those issues are:

** Altering read-only property through Sequence interface throws wrong Exception.
Expected Behavior:  UnsupportedOperationException is thrown
Observed Behavior:  RuntimeException
Cause:  In BasicFeatureMap, if (!eStructuralFeature.isChangeable()) a RuntimeException is thrown.
Problem:  That is EMF code.  It is bad form to catch RuntimeException (somewhat analogous to catching Exception), so it would be unwise to try to catch this in SDO code simply to throw UnsupportedOperationException.


** Expected Exceptions from the List interface.
Expected Behavior:   (e.g.  List.get(-1) should throw an IndexOutOfBoundsException)
Observed Behavior:  (e.g.  List.get(-1) throws NullPointerException, in some cases)
Note:  Similar statements hold for using the List interface to alter a read-only Property
Problem:   The List method calls fall directly into the EMF List implementations.  There is not an SDO layer with which we could try to catch various Exceptions and throw the one indicated in our spec.


** DataObject.get(property) with an invalid property does not throw the appropriate Exception in the static case.
Note:  This test case is done using property1 from type1, and dataObject2 of type2.  Calling dataObject2.get(property1) should throw the appropriate Exception, and does so in the dynamic cases.
Expected Behavior:  IllegalArgumentException is thrown
Observed Behavior: No Exception is thrown.  Instead, the get() is performed using the Property index (index in the other type) of the invalid property.  The property in type2 (the DataObject)  that happens to have the same index value as property1 in type1 is not meaningful, but that is what is used.
Cause:  eDerivedStructuralFeatureID(eFeature) should return -1 and does so in the dynamic case.  However in the static case this method is handled by BasicEObjectImpl., which determines the containingClass but never uses it in any way.  The containingClass should be used to determine that the property is not valid for that class. 
Problem:  This is EMF code.


Please let me know your thoughts on the outstanding issues.  

If you agree that they cannot be reasonably corrected, and you agree that the test case covers the complete set of explicitly identified Exceptions then please mark the Jira fixed.

> Exceptions thrown by SDO runtime not the same as defined in the spec
> --------------------------------------------------------------------
>
>                 Key: TUSCANY-578
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-578
>             Project: Tuscany
>          Issue Type: Bug
>          Components: Java SDO Implementation
>    Affects Versions: Java-M2
>            Reporter: Brian Murray
>            Priority: Minor
>             Fix For: Java-SDO-Mx
>
>         Attachments: 578.patch, 578.zip, DataObjectUtil.patch
>
>
> On page 27 of V2.01 of the spec, specific exceptions are listed for certain kinds of errors.  In some cases, a different exception is thrown (each case will be added as a subtask).  Either the specification or the implementation should be updated.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org