[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [jdt-core-dev] CAUTION: IClassFile.getType() will no longer throwJavaModelException
|
Thanks for the warning, Frederic.
If you release the change on Friday after the N20070302-0010 build has started, then I can update jdt.apt.core in time for the Saturday build.
Or if you would prefer, you can just commit the change yourself. (The code should function correctly without the catch block; it is not assuming anything about the model being populated, as far as I can tell.) Here's the patch to apply:
### Eclipse Workspace Patch 1.0
#P org.eclipse.jdt.apt.core
Index: src/org/eclipse/jdt/apt/core/internal/env/BaseProcessorEnv.java
===================================================================
RCS file: /cvsroot/eclipse/org.eclipse.jdt.apt.core/src/org/eclipse/jdt/apt/core/internal/env/BaseProcessorEnv.java,v
retrieving revision 1.29
diff -u -r1.29 BaseProcessorEnv.java
--- src/org/eclipse/jdt/apt/core/internal/env/BaseProcessorEnv.java 10 Feb 2007 02:32:39 -0000 1.29
+++ src/org/eclipse/jdt/apt/core/internal/env/BaseProcessorEnv.java 28 Feb 2007 16:20:54 -0000
@@ -581,10 +581,7 @@
catch (JavaModelException e) {}
}
else if (classFile != null) {
- try {
- type = classFile.getType();
- }
- catch (JavaModelException e) {}
+ type = classFile.getType();
}
// Given a type, we can construct a package declaration impl from it,
-----Original Message-----
From: jdt-core-dev-bounces@xxxxxxxxxxx [mailto:jdt-core-dev-bounces@xxxxxxxxxxx] On Behalf Of Frederic Fusier
Sent: Wednesday, February 28, 2007 7:47 AM
To: jdt-dev@xxxxxxxxxxx; jdt-core-dev@xxxxxxxxxxx; jdt-ui-dev@xxxxxxxxxxx; jdt-apt-dev@xxxxxxxxxxx; jdt-debug-dev@xxxxxxxxxxx
Subject: [jdt-core-dev] CAUTION: IClassFile.getType() will no longer throwJavaModelException
There is currently an inconsistency on IClassFile#getType() method which throws a JavaModelException although its implementation does not (see bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=154667).
This is also confusing for clients who may think that calling this method will populate the model although it does not (this is a handle-only method).
** We definitely want to fix this problem in next week integration build **
Note that, if this change has no impact on binary compatibility, it breaks source compatibility! Clients of this API must remove unnecessary catch block in their code as it will become invalid and be flagged as error by the compiler.
**********************************************************************
**** We plan to release this change in JDT/Core HEAD next Friday *****
**********************************************************************
Here are the 'Unreachable catch block' compiler errors got after having applied the patch in an Eclipse full source workspace using I20070227-0800
build:
plugin org.eclipse.jdt.apt.core
===============================
- /src/org/eclipse/jdt/apt/core/internal/env
BaseProcessorEnv.java: line 587
plugin org.eclipse.jdt.debug.ui
===============================
- /src/org/eclipse/jdt/internal/debug/ui
TypeNameResolver.java: line 59
plugin org.eclipse.jdt.ui
=========================
- /src/org/eclipse/jdt/internal/corext/refactoring/rename
GenericRefactoringHandleTransplanter.java: line 122
- /src/org/eclipse/jdt/internal/ui/browsing
MembersView.java: line 264
- /src/org/eclipse/jdt/internal/ui/browsing
TypesView.java: line 135
- /src/org/eclipse/jdt/internal/ui/infoviews
JavadocView.java: line 505
- /src/org/eclipse/jdt/internal/ui/javaeditor
InternalClassFileEditorInput.java: line 83
- /src/org/eclipse/jdt/internal/ui/javaeditor
JavaOutlinePage.java: line 973
- /src/org/eclipse/jdt/internal/ui/text
JavaOutlineInformationControl.java: line 789
- /src/org/eclipse/jdt/internal/ui/typehierarchy
TypeHierarchyLifeCycle.java: line 239
- /src/org/eclipse/jdt/internal/ui/typehierarchy
TypeHierarchyViewPart.java: line 1608
- /src/org/eclipse/jdt/ui/actions
FindAction.java: line 201
JDT/APT, JDT/UI and JDT/Debug please confirm by answering to this post that you will be able to release corresponding change in HEAD on Friday and avoid a failure in Saturday nightly build, thanks
Note that there are other references to this method in the workspace but they won't be broken by this change as they do no catch the exception (declaring method already throws the JME) or there's a call to another method which also throws the JME in the same try block...
I will also add an entry in 3.3 migration guide to document this change for other potential clients of this API.
Cordialement/Regards,
Frédéric
_______________________________________________
jdt-core-dev mailing list
jdt-core-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jdt-core-dev
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.