Community
Participate
Working Groups
Build Identifier: 20111030 nightly build Generated Java code got error for "Unhandled exception". For this bug blocked some points in RUI access LDAP Green Thread testing, I set the severity to major. Reproducible: Always Steps to Reproduce: 1. Download the attached EDT EGL project, import to your workspace 2. Make sure there is no EGL compile error. 3. See the file "common.LDAPLib.java" in generatedJava, there are some Java compile error of "Unhandled exception" (line 213, 218, 220 and so on). 4. The doesn't occurred in RBD, you may get comparable project in RBD by Help => Samples => EGL => Rich UI access to LDAP. The RBD generated java will throw exception "java.lang.Exception"
Created attachment 206190 [details] LdapRuiServices in EDT
There is currently now way to indicate that a function throws an exception.
I spoke with Joe about this, and I believe the story goes as follows: 1) In RBD we had a keyword 'throws' that could be placed on the External Type function to indicate it would throw an exception. The generators would handle this accordingly by wrapping the invocation in a try/catch. 2) In EDT we originally introduced the ThrowsException annotation, but this was eventually removed as it appeared we did not have a use for it in the .7 time frame. At this point, we need to decide how many scenarios are broken if a user develops an ET with a function that throws an exception. One easy workaround is to wrap the Java object with another class that is written to handle the exception, but this would not make sense if it causes a lot of wrapper objects to be written. Jeff, can you describe how this would be implemented and provide a rough sizing for an implementation of the ThrowsException in the Java generator? If you have any questions or concerns about how it would be implemented, please include them here. Would we just always catch Exception coming from the invoked ET function and return an EDT exception? Does the implementation in RBD, assuming it ports directly to EDT (within reason) make sense, and is it something we want to port? Jing, assuming the sizing is small, and there are no questions about the design or implementation, are you ok with us including this in .7? It sounds like it would at least be tested in the .7 release with the LDAP sample. If the design changed at all from RBD, I think we would defer it out of .7 and require users to wrapper the java class with their own class definition that catches the exception.
If we simply just allow the egl function to be defined with an annotation of "throws exception", then we could simply add "throws exception" to the java method being generated. That would be a quick thing to change. Anything more elaborate would require more time and I cannot estimate unless a spec is given.
In the scrum status this is listed as a blocking issue. Here is a workaround and if we don't come up with a solution to this problem this is also what the customer will have to do. For any ExternalType JavaObject function that throws an exception the user will have to add a try/onexception. There are 2 ways to find the functions that throw exceptions: 1. Look at the JavaDoc for the class. 2. Look at the unhandled exceptions in the generated Java code.
This was resolved in 080. The external type tooling for java creates external types with throws. So for this test case the external types need to be recreated so they have the throws. Then the testcase must be updated with try/onexception to handle the possibility of an exception.
