Bugzilla – Full Text Bug Listing
| Summary: | Error opening zip file in JDT | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Ulrich Hobelmann <ulrich.hobelmann> |
| Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | jarthana, stephan.herrmann |
| Version: | 4.6 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | stalebug | ||
|
Description
Ulrich Hobelmann
This exception definitely lacks relevant information. URLConnection.getInputStream() doesn't seem to provide this information when somewhere inside a ZipException is thrown. JavaElement.getURLContents() is in a good position to fill in this information (e.g., inside an addition specific "catch (ZipException e)"), but I'm not 100% sure which is the best strategy for combining the exception + additional message parts into a JavaModelStatus or JavaModelException. Perhaps the catch block from MalformedURLException gives a good example: throw new JavaModelException(new JavaModelStatus(IJavaModelStatusConstants.CANNOT_RETRIEVE_ATTACHED_JAVADOC, this)) Maybe, this form should be preferred for several of the caught-wrapped-rethrown exceptions? @Jay, @Manoj, what's your say? (In reply to Stephan Herrmann from comment #1) > JavaElement.getURLContents() is in a good position to fill in this > information (e.g., inside an addition specific "catch (ZipException e)"), > but I'm not 100% sure which is the best strategy for combining the exception > + additional message parts into a JavaModelStatus or JavaModelException. > Perhaps the catch block from MalformedURLException gives a good example: > throw new JavaModelException(new > JavaModelStatus(IJavaModelStatusConstants.CANNOT_RETRIEVE_ATTACHED_JAVADOC, > this)) Not sure I understand your point. This example only captures the current element and not the URL we are trying to open. (In reply to Jay Arthanareeswaran from comment #2) > (In reply to Stephan Herrmann from comment #1) > > JavaElement.getURLContents() is in a good position to fill in this > > information (e.g., inside an addition specific "catch (ZipException e)"), > > but I'm not 100% sure which is the best strategy for combining the exception > > + additional message parts into a JavaModelStatus or JavaModelException. > > Perhaps the catch block from MalformedURLException gives a good example: > > throw new JavaModelException(new > > JavaModelStatus(IJavaModelStatusConstants.CANNOT_RETRIEVE_ATTACHED_JAVADOC, > > this)) > > Not sure I understand your point. This example only captures the current > element and not the URL we are trying to open. Your're right, but that would already be way better than what we have today: no information at all :-/ OTOH, does JavaModelStatus support custom exception details? (In reply to Stephan Herrmann from comment #3) > Your're right, but that would already be way better than what we have today: > no information at all :-/ > > OTOH, does JavaModelStatus support custom exception details? I see that creating a JMException with an exception does propagate the exception to the newly created JavaModelStatus. Clients are free to make use of it via org.eclipse.core.runtime.Status.getException(). That is what the currently effective catch block is doing, but clearly we are not getting the right message in the log. For the records, a similar issue was reported in apt (bug 474770). If the ZipException doesn't contain the troublesome file name, perhaps we can simply log the error before creating the JME? This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |