diff options
author | Reinier Zwitserloot <reinier@tipit.to> | 2009-06-30 18:22:38 +0200 |
---|---|---|
committer | Reinier Zwitserloot <reinier@tipit.to> | 2009-06-30 18:22:38 +0200 |
commit | 37006cb2954b6fcb23d2dcfaedbc3abac3fbb5d7 (patch) | |
tree | de6f4a782753fe81c8809771fdae638f2bd7d8e0 /src/lombok/eclipse/EclipseAST.java | |
parent | e0b623a3b85c89028bfc8c52578232b1c539723c (diff) | |
download | lombok-37006cb2954b6fcb23d2dcfaedbc3abac3fbb5d7.tar.gz lombok-37006cb2954b6fcb23d2dcfaedbc3abac3fbb5d7.tar.bz2 lombok-37006cb2954b6fcb23d2dcfaedbc3abac3fbb5d7.zip |
After a great many iterations, Cleanup has now been reduced in functionality (exceptions from the cleanup call WILL mask exceptions from the body - this isn't intended, but it's just not possible to fix this without java 7 features or requiring a rewrite of the class file data.
Tried tactics, and why they won't work:
- Replace every 'return', 'break', and 'continue' statement (for the latter 2, only if they break/continue out of the try block) with a block that first sets a uniquely named flag before doing the operation.
Then, check that flag in the finally block to see if the cleanup call should be guarded by a try/catchThrowable. This doesn't work, because its not possible to instrument the 4th way out of a try block without throwing an exception: Just letting it run its course. Tossing a "#flag = true;" at the end may cause a compile time error if the code is not reachable, but figuring that out requires resolution and quite a bit of analysis.
- Put catch blocks in for all relevant exceptions (RuntimeException, Error, all exceptions declared as thrown by the method, and all types of exceptions of the catch blocks of encapsulating try blocks.
This doesn't work, partly because it'll fail for sneakily thrown exceptions, but mostly because you can't just catch an exception listed in the 'throws' clause of the method body; catching an exception
that no statement in the try block can throw is a compile time error, but it is perfectly allright to declare these as 'thrown'.
- Put in a blanket catch Throwable to set the flag. Two problems with this:
First, sneaky throw can't be done. Thread.stop invokes a security manager and triggers a warning, Calling a sneakyThrow method creates a runtime dependency on lombok, constructing a sneakyThrow in-class creates visible methods or at least visible class files, and creating a new class via Class.loadClass would be very slow without caching - which gets you the same issues.
Secondly, this would mean that any statements in the try body that throw an exception aren't flagged to the user as needing to be handled.
The Cleanup annotation now also calls the cleanup method for you, and will call it at the END of the current scope. The following plans have been tried and abandoned:
- Cleanup right after the final mention. This doesn't work, because the final mention may not be the final use-place. Example:
@Cleanup InputStream in = new FileInputStream(someFile);
InputStreamReader reader = new InputStreamReader(in);
reader.read(); //oops - in is already closed by now.
- Require an explicit var.cleanup() call and consider that the cue to close off the try block.
This doesn't work either, because now variables set in between the @Cleanup declaration and the var.cleanup() call become invisible to following statements. Example:
@Cleanup InputStream in = new FileInputStream(someFile);
int i = in.read();
in.close();
System.out.println(i); //fail - i is inside the generated try block but this isn't, so 'i' is not visible from here.
By running to the end of visible scope, all these problems are avoided. This does remove the flexibility of declaring where you want a close call to be executed, but there are two mitigating factors available:
1) Create an explicit scope block. You can just stick { code } in any place where you can legally write a statement, in java. This is relatively unknown, so I expect most users will go for:
2) Just call close explicitly. I've yet to see a cleanup method which isn't idempotent anyway (calling it multiple times is no different than calling it once).
During the course of investigating these options, the AST code has been extended to support live replacement of any child node, including updating the actual underlying system AST as well as our own.
Unfortunately, this code has NOT been tested. It was rather a lot of work so I'm leaving it in, and at least for eclipse it even seemed to work.
Diffstat (limited to 'src/lombok/eclipse/EclipseAST.java')
-rw-r--r-- | src/lombok/eclipse/EclipseAST.java | 18 |
1 files changed, 7 insertions, 11 deletions
diff --git a/src/lombok/eclipse/EclipseAST.java b/src/lombok/eclipse/EclipseAST.java index c5bdd2ff..5b2b153d 100644 --- a/src/lombok/eclipse/EclipseAST.java +++ b/src/lombok/eclipse/EclipseAST.java @@ -143,7 +143,7 @@ public class EclipseAST extends AST<ASTNode> { } public final class Node extends AST<ASTNode>.Node { - Node(ASTNode node, Collection<Node> children, Kind kind) { + Node(ASTNode node, List<Node> children, Kind kind) { super(node, children, kind); } @@ -300,7 +300,7 @@ public class EclipseAST extends AST<ASTNode> { private static String toFileName(CompilationUnitDeclaration ast) { return ast.compilationResult.fileName == null ? null : new String(ast.compilationResult.fileName); } - + public void reparse() { propagateProblems(); if ( completeParse ) return; @@ -349,7 +349,7 @@ public class EclipseAST extends AST<ASTNode> { } private Node buildCompilationUnit(CompilationUnitDeclaration top) { - Collection<Node> children = buildTypes(top.types); + List<Node> children = buildTypes(top.types); return putInMap(new Node(top, children, Kind.COMPILATION_UNIT)); } @@ -357,7 +357,7 @@ public class EclipseAST extends AST<ASTNode> { if ( n != null ) collection.add(n); } - private Collection<Node> buildTypes(TypeDeclaration[] children) { + private List<Node> buildTypes(TypeDeclaration[] children) { if ( children == null ) return Collections.emptyList(); List<Node> childNodes = new ArrayList<Node>(); for ( TypeDeclaration type : children ) addIfNotNull(childNodes, buildType(type)); @@ -381,9 +381,9 @@ public class EclipseAST extends AST<ASTNode> { return childNodes; } - private static <T> Collection<T> singleton(T item) { + private static <T> List<T> singleton(T item) { if ( item == null ) return Collections.emptyList(); - else return Collections.singleton(item); + else return Collections.singletonList(item); } private Node buildField(FieldDeclaration field) { @@ -454,21 +454,17 @@ public class EclipseAST extends AST<ASTNode> { return childNodes; } - //Almost anything is a statement, so this method has a different name to avoid overloading confusion private Node buildStatement(Statement child) { if ( child == null || alreadyHandled(child) ) return null; if ( child instanceof TypeDeclaration ) return buildType((TypeDeclaration)child); if ( child instanceof LocalDeclaration ) return buildLocal((LocalDeclaration)child, Kind.LOCAL); - //We drill down because LocalDeclarations and TypeDeclarations can occur anywhere, even in, say, - //an if block, or even the expression on an assert statement! - setAsHandled(child); return drill(child); } - protected Node drill(Statement statement) { + private Node drill(Statement statement) { List<Node> childNodes = new ArrayList<Node>(); for ( FieldAccess fa : fieldsOf(statement.getClass()) ) childNodes.addAll(buildWithField(Node.class, statement, fa)); return putInMap(new Node(statement, childNodes, Kind.STATEMENT)); |