To follow up on this, in other words, I am surprised that this process... method doesn't take an arbitrary statement (like a block).>>> Raffi Khatchadourian 07/27/15 11:06 AM >>> Actually, I am not too sure about this method (i.e., org.eclipse.jdt.internal.codeassist.ThrownExceptionFinder.getThrownUncaughtExceptions()). It seems that the method to call first is ThrownExceptionFinder.processThrownExceptions(TryStatement, BlockScope), however, I am a little surprised that it requires a TryStatement. Certainly, you can throw an uncaught exception without a try statement so as long as you declare that the surrounding methods throws that exception (assuming it is a checked exception, of course). Thoughts?
>>> Stephan Herrmann <stephan.herrmann@xxxxxxxxx> 07/23/15 1:05 PM >>> I'm glad to hear that you already have your answer. I could keep asking what you mean by "more appropriate" but we probably don't need to dive deeper into this, right?
Stephan
On 07/23/2015 12:36 PM, Raffi Khatchadourian wrote: > Hi Stephan, > > Sorry about the confusion. Basically, we would like to check that a block of code (e.g., a for loop body) does not throw checked > exceptions. Note that, if a block of code *does* throw a checked exception, the code will compile *so as long *as the method > header/signature has a throws clause. Here's an example: > > void m() throws Exception { > for (...) { > throw new Exception(); //bad. > } > for (...) { > //good. > } > } > > Note that this is not as simple as just checking for *throw* statements in the AST of the loop body as the body may call methods > that throw exceptions and the throw could appear in a try/catch block that does not rethrow the exception. > > I found a method org.eclipse.jdt.internal.codeassist.ThrownExceptionFinder.getThrownUncaughtExceptions() that seems to be what we > need but just wanted to get some feedback about any more appropriate methods. > > >>> "Stephan Herrmann" <stephan.herrmann@xxxxxxxxx> 07/22/15 9:50 PM >>> > Now you got me confused. > If there are no compile errors, what do you mean by uncaught exceptions?? > > Are you thinking of those elements that are marked (mark occurrences) when you select an exception after "throws" in a Java editor? > > ----- ursprüngliche Nachricht --------- > > Subject: Re: [jdt-ui-dev] [jdt-core-dev] Is there a method similar to the NetBeans TreeUtilities.getUncaughtExceptions() method in > the Eclipse JDT? > Date: Mi 22 Jul 2015 19:08:27 CEST > From: Raffi Khatchadourian<rkhatchadourian@xxxxxxxxxxxxxxxxx> > To: stephan.herrmann@xxxxxxxxx, jdt-core-dev@xxxxxxxxxxx, jdt-ui-dev@xxxxxxxxxxx > > Actually, we are assuming that the code compiles correctly. Here > <https://urldefense.proofpoint.com/v2/url?u=http-3A__bits.netbeans.org_7.0_javadoc_org-2Dnetbeans-2Dmodules-2Djava-2Dsource_org_netbeans_api_java_source_TreeUtilities.html-23getUncaughtExceptions-28com.sun.source.util.TreePath-29&d=AwMFaQ&c=pRW6ZPn_LDv0DnDIAK65Ad0CA4hBS-2mAmNa2_oHfF0&r=ZWMXxXoMJXDPt1UmtqAbqkaR0taI35-hbHULr4xuoc_rqRVB5VCJXyB9HEfLF8Rw&m=gLkJD-YOjs5nTlZ-hL3OBoiLr8Nw-Z-BKieMsofmXzo&s=Xycs0vMLyzgFLle-Q7dEpLvPuvo4jeeBXrmhsFgpbzw&e=> > is the API documentation and here > <https://urldefense.proofpoint.com/v2/url?u=http-3A__grepcode.com_file_bits.netbeans.org_maven2_org.netbeans.api_org-2Dnetbeans-2Dmodules-2Djava-2Dsource_RELEASE73-2DBETA_org_netbeans_api_java_source_TreeUtilities.java-23TreeUtilities.getUncaughtExceptions-2528com.sun.source.util.TreePath-2529&d=AwMFaQ&c=pRW6ZPn_LDv0DnDIAK65Ad0CA4hBS-2mAmNa2_oHfF0&r=ZWMXxXoMJXDPt1UmtqAbqkaR0taI35-hbHULr4xuoc_rqRVB5VCJXyB9HEfLF8Rw&m=gLkJD-YOjs5nTlZ-hL3OBoiLr8Nw-Z-BKieMsofmXzo&s=nvoBG6Tju5WNECZqoOxUm3yAIVBfV-5BTYxi2AG8BHE&e=> > is the source code. > > >>> "Stephan Herrmann" <stephan.herrmann@xxxxxxxxx> 07/22/15 1:48 PM >>> > I would think of leveraging the existing IProblems along these lines: > - retrieve the problems from the compilation unit declaration > - filter for id == IProblem.UnhandledException > - perhaps also filter per source range > > Unfortunately, finding the referenced exception type might require reverse-engineering the problem message. > Or you use the source range of the problem for identifying the offending AST node, and then inspect its resolvedBinding() > (should be a MethodBinding). > > HTH, > Stephan > > > ----- ursprüngliche Nachricht --------- > > Subject: Re: [jdt-core-dev] Is there a method similar to the NetBeans TreeUtilities.getUncaughtExceptions() method in the Eclipse JDT? > Date: Di 21 Jul 2015 11:50:20 CEST > From: Raffi Khatchadourian<RKhatchadourian@xxxxxxxxxxxxxxxxx> > To: jdt-core-dev@xxxxxxxxxxx, jdt-ui-dev@xxxxxxxxxxx > > Sorry, meant to say uncaught *exceptions* (not messages). > > > >>> Raffi Khatchadourian 07/21/15 10:14 AM >>> > NetBeans source code analysis has a method |org.netbeans.api.java.source.TreeUtilities.getUncaughtExceptions(TreePath)| that > retrieves uncaught messages from an AST subtree. Does the Eclipse JDT have a similar method? > > > ---- ursprüngliche Nachricht Ende ---- > > ---- ursprüngliche Nachricht Ende ----
|