Community
Participate
Working Groups
Currently the DI framework in Eclipse gives a long stacktrace if a method cannot be called. This stacktrace shows only the internal code of the DI framework. I think we should catch the exception and only return the error message. Here is an example for such a stack trace. org.eclipse.e4.core.di.InjectionException: Unable to find matching method to invoke at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:215) at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:90) at org.eclipse.e4.core.internal.tests.di.InvokeTestNegative.testSuperclassMethods(InvokeTestNegative.java:37) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at junit.framework.TestCase.runTest(TestCase.java:176) at junit.framework.TestCase.runBare(TestCase.java:141) at junit.framework.TestResult$1.protect(TestResult.java:122) at junit.framework.TestResult.runProtected(TestResult.java:142) at junit.framework.TestResult.run(TestResult.java:125) at junit.framework.TestCase.run(TestCase.java:129) at junit.framework.TestSuite.runTest(TestSuite.java:255) at junit.framework.TestSuite.run(TestSuite.java:250) at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:62) at org.eclipse.pde.internal.junit.runtime.PlatformUITestHarness$1.run(PlatformUITestHarness.java:47) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:136) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3746) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3394) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1122) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1006) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:160) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:620) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:571) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:125) at org.eclipse.pde.internal.junit.runtime.NonUIThreadTestApplication.runApp(NonUIThreadTestApplication.java:54) at org.eclipse.pde.internal.junit.runtime.UITestApplication.runApp(UITestApplication.java:47) at org.eclipse.pde.internal.junit.runtime.NonUIThreadTestApplication.start(NonUIThreadTestApplication.java:48) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:109) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:80) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:372) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:226) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591) at org.eclipse.equinox.launcher.Main.run(Main.java:1450) at org.eclipse.equinox.launcher.Main.main(Main.java:1426)
Except the important part of the message is embedded in the stack trace. org.eclipse.e4.core.internal.tests.di.InvokeTestNegative.testSuperclassMethods(InvokeTestNegative.java:37) PW
(In reply to Paul Webster from comment #1) > Except the important part of the message is embedded in the stack trace. > > org.eclipse.e4.core.internal.tests.di.InvokeTestNegative. > testSuperclassMethods(InvokeTestNegative.java:37) Was this comment meant for Bug 426755? I had to put the stack trace into a try/catch block to make the test successful but to see the stack trace I removed the first statement out of the try block.
This improved error message will be very helpful for hunting down problems in customer implementations and training sessions. I hope you like it, it is currently based on the Gerrit review for Bug 426755, in case you dislike the additional test, I can rebase onto master. https://git.eclipse.org/r/21165 To see the new error message, use the test from Bug 426755 and move ContextInjectionFactory.invoke(editor, Execute.class, EclipseContextFactory .create()); out of the try/catch block.
Rebased onto master, just in case.
(In reply to Lars Vogel from comment #0) > Currently the DI framework in Eclipse gives a long stacktrace if a method > cannot be called. This stacktrace shows only the internal code of the DI > framework. I think we should catch the exception and only return the error > message. Oh, I misunderstood "I think we should catch the exception and only return the error message." It looks like you've just updated the exception to include more information about the call (and it still has the stack trace). PW
(In reply to Paul Webster from comment #5) > Oh, I misunderstood "I think we should catch the exception and only return > the error message." It looks like you've just updated the exception to > include more information about the call (and it still has the stack trace). Sorry, the description was incorrect. Yes, I included more infos into the error message which I think will be helpful to find problems with injections.
Fixed with http://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/?id=9202918ad595a7a50353f2bbf7bf59b00fa4b54b
Mini update https://git.eclipse.org/c/platform/eclipse.platform.runtime.git/commit/?id=ccafb85b5fe919a60c7d57dd580fd021bd4c3a7e
These look like they're going into M6. PW
(In reply to Paul Webster from comment #9) > These look like they're going into M6. > PW Thanks. I was unaware that we are still building.
