Community
Participate
Working Groups
4.3 M5a. Currently JDT Core ignores some exceptions and returns 'null'. This violates the API/Javadoc. Bug 400060 tracks that part. Once this is fixed we need to adjust our code to handle those exceptions and show them to the user without logging them.
The exceptions ignored by JDT Core are 1. FileNotFoundException => thrown when the url provided is wrong, 2. UnKnownHostException => thrown when the network is down 3. SocketException => thrown when the site we are trying to access is down. 4. ProtocolException => similar to SocketException, thrown when there is some problem with the network. Except the first exception the remaining are network related failure. So would the below be an appropriate message to be shown to the user requesting for the corresponding Javadoc: "Note:The attached Javadoc could not be retrieved either due to network error or due to incorrect Javadoc URL." If two possible reason for failure should not be shown in a single message, then we can filter the FNF and show message: "Note:The attached Javadoc could not be retrieved due to incorrect Javadoc URL. Verify the Javadoc URL provided." and for others "Note:The attached Javadoc could not be retrieved due to network error." Dani kindly share your thoughts.
> Except the first exception the remaining are network related failure. The first could have a similar symptom, e.g. when a mounted drive is not present. > So would > the below be an appropriate message to be shown to the user > requesting for the corresponding Javadoc: > "Note:The attached Javadoc could not be retrieved either due to network error > or due to incorrect Javadoc URL." I would use a more generic wording: The specified Javadoc location is either wrong or currently not accessible.
Created attachment 227457 [details] Fix. If the attached Javadoc cannot be retrieved, then user is informed it via the Javadoc Hover and the Javadoc View. The message shown will be "Note: The attached Javadoc could not be retrieved as the specified Javadoc location is either wrong or currently not accessible.". The exception is not logged.
Patch is almost good. Just two issues: - #handleFailedJavadocFetch does not belong into JavadocContentAccess2 but into the same class where we already have the explanation helper method - #handleFailedJavadocFetch should have CoreException as parameter type. If so, you don't need to check/cast to JME, but instead only check the code and the exception.
(In reply to comment #4) > - #handleFailedJavadocFetch should have CoreException as parameter type. If > so, you don't need to check/cast to JME, but instead only check the code > and the exception. One more thing: we must also check the plug-in ID, since the codes are not global but per plug-in. In addition, please add Javadoc to the new method.
Created attachment 227521 [details] Fix and Testcase. 1. #handleFailedJavadocFetch is moved to JavadocLocations and added Javadoc for this method. 2. #handleFailedJavadocFetch takes CoreException as the parameter and inside this method we check whether the exception is thrown from org.eclipse.jdt.core plugin. 3. Added a testcase in PackageJavadocTests to test the case when the Javadoc loctaion URL is wrong. Dani, kindly verify.
There are still some issues: 1) missing @since tag 2) we write "Java element" not any other variant 3) the name of the new test has a typo 4) the new test fails until JDT Core has committed their change In addition, we should not catch all IOExceptions (this was an oversight in my first review), but just those which we no longer silently catch. I've committed your patch and then fixed those issues with http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=8113b4866b38554c893cd820c6ff60dbffcf9379
Verified in I20130311-2000. There was on regression, see bug 403036 for details.
