Community
Participate
Working Groups
I20060428-0010 IMethod#getParameterNames() should not throw JME if javadoc is not parseable or not available. Currently, it e.g. throws an exception when called on a private binary method where a source attachment is not avaliable and the javadoc does not include private members. Steps: Open Java Editor on java.util.Collections from a 1.5 rt.jar and select iteratorBinarySearch(List<? extends Comparable<? super T>>, T) in the Outline. The exception occurs because the status line wants to display the parameter names (source is not available for this method due to bug xxx). If you remove the source from the rt.jar, it also fails for all the other private methods. Java Model Exception: Java Model Status [Unknown javadoc format for iteratorBinarySearch(java.util.List<? extends java.lang.Comparable<? super T>>, T) [in Collections [in Collections.class [in java.util [in C:\java\jdk1.5.0_06\jre\lib\rt.jar [in JUnit1.5]]]]]] at org.eclipse.jdt.internal.core.BinaryMethod.extractJavadoc(BinaryMethod.java:596) at org.eclipse.jdt.internal.core.BinaryMethod.getParameterNames(BinaryMethod.java:230) at org.eclipse.jdt.ui.JavaElementLabels.getMethodLabel(JavaElementLabels.java:531) at org.eclipse.jdt.ui.JavaElementLabels.getElementLabel(JavaElementLabels.java:418) at org.eclipse.jdt.ui.JavaElementLabels.getElementLabel(JavaElementLabels.java:395) at org.eclipse.jdt.internal.ui.viewsupport.StatusBarUpdater.formatJavaElementMessage(StatusBarUpdater.java:89) at org.eclipse.jdt.internal.ui.viewsupport.StatusBarUpdater.formatMessage(StatusBarUpdater.java:71) at org.eclipse.jdt.internal.ui.viewsupport.StatusBarUpdater.selectionChanged(StatusBarUpdater.java:56) at org.eclipse.jface.viewers.StructuredViewer$3.run(StructuredViewer.java:833) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.runtime.Platform.run(Platform.java:843) at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:44) at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:149) at org.eclipse.jface.viewers.StructuredViewer.firePostSelectionChanged(StructuredViewer.java:831) at org.eclipse.jface.viewers.StructuredViewer.handlePostSelect(StructuredViewer.java:1137) at org.eclipse.jface.viewers.StructuredViewer$5.widgetSelected(StructuredViewer.java:1157) at org.eclipse.jface.util.OpenStrategy.firePostSelectionEvent(OpenStrategy.java:236) at org.eclipse.jface.util.OpenStrategy.access$4(OpenStrategy.java:230) at org.eclipse.jface.util.OpenStrategy$3.run(OpenStrategy.java:404) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:123) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3325) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2971) at org.eclipse.jface.window.Window.runEventLoop(Window.java:820) at org.eclipse.jface.window.Window.open(Window.java:796) at org.eclipse.pde.internal.runtime.logview.EventDetailsDialog.open(EventDetailsDialog.java:183) at org.eclipse.pde.internal.runtime.logview.EventDetailsDialogAction.run(EventDetailsDialogAction.java:91) at org.eclipse.pde.internal.runtime.logview.LogView$13.doubleClick(LogView.java:403) at org.eclipse.jface.viewers.StructuredViewer$1.run(StructuredViewer.java:790) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.runtime.Platform.run(Platform.java:843) at org.eclipse.ui.internal.JFaceUtil$1.run(JFaceUtil.java:44) at org.eclipse.jface.util.SafeRunnable.run(SafeRunnable.java:149) at org.eclipse.jface.viewers.StructuredViewer.fireDoubleClick(StructuredViewer.java:788) at org.eclipse.jface.viewers.AbstractTreeViewer.handleDoubleSelect(AbstractTreeViewer.java:1210) at org.eclipse.jface.viewers.StructuredViewer$4.widgetDefaultSelected(StructuredViewer.java:1152) at org.eclipse.jface.util.OpenStrategy.fireDefaultSelectionEvent(OpenStrategy.java:223) at org.eclipse.jface.util.OpenStrategy.access$0(OpenStrategy.java:220) at org.eclipse.jface.util.OpenStrategy$1.handleEvent(OpenStrategy.java:281) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:925) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2968) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1914) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1878) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:419) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:143) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:95) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:78) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336) at org.eclipse.core.launcher.Main.basicRun(Main.java:280) at org.eclipse.core.launcher.Main.run(Main.java:977) at org.eclipse.core.launcher.Main.main(Main.java:952)
Then if the anchor is not found, I should not log an error. But this could have two explanations: wrong computing of the anchor or missing anchor. Do you suggest not to log any exception in both cases?
Created attachment 39858 [details] Proposed fix Philippe, Candidate for RC3?
Philippe, Candidate for RC3?
(In reply to comment #1) > Then if the anchor is not found, I should not log an error. > But this could have two explanations: wrong computing of the anchor or missing > anchor. > Do you suggest not to log any exception in both cases? Yes. People will file bugs anyway if javadoc attachments don't show up, so we don't need an exception. Missing anchors have to be expected with partial, outdated, or customized javadoc, and no exception should be thrown for expected failures. However, I think this only applies to IJavaElement#getAttachedJavadoc(..). For the case in comment 0, the fix should also make sure that IMethod#getParameterNames() never throws a JME, not even if the Javadoc is malformed or something (i.e. add a try {..} catch (JavaModelException e) { } around BinaryMethod.java:230, rev. 1.89).
Created attachment 40016 [details] Better patch This patch adds a try/catch around the extraction of the javadoc for the binary method.
Candidate for RC3? Patch is ready.
+1 for 3.2RC3. Being resilient is good here. It will revert to inferring arg0... argN. Dani/Markus - pls cast your vote.
+1 for 3.2 RC3.
Fixed and released in HEAD. Regression test added in org.eclipse.jdt.core.tests.model.AttachedJavadocTests.test020
Verified using N20060503-0010 for 3.2RC3
Double-checked using N20060504-0010 + JDT/Core v_663. Note that this exception does not occur with 3.2 RC2 but only with I20060428-0010.
