History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: GROOVY-2666
Type: Bug Bug
Status: Closed Closed
Resolution: Cannot Reproduce
Priority: Blocker Blocker
Assignee: Alex Tkachman
Reporter: Reto Kleeb
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
groovy

Different exception behavior in groovy 1.6 (original exception is wrapped)

Created: 07/Mar/08 11:27 AM   Updated: 03/May/08 11:14 PM
Component/s: None
Affects Version/s: 1.6-beta-1
Fix Version/s: 1.6-beta-1

Time Tracking:
Not Specified

Environment: groovy 1.6beta snapshot from the canoo ci server (http://build.canoo.com/groovy/artifacts/20080303213011)
Issue Links:
Related
 


 Description  « Hide
The current SVN Head code handles exceptions differently than groovy 1.5.4 or earlier. This change in the behavior is a breaking change for some existing code:

Example Code from the groovy-eclipse project: org.codehaus.groovy.eclipse.astviews, TreeNodeFactory.groovy, Class DefaultTreeNode#loadChildren:

try {
return TreeNodeFactory.createTreeNode(this, value."${method.name}"(), name)
} catch (org.codehaus.groovy.GroovyBugError e) {
// Some getters are not for us.
return null
} catch (NullPointerException e) {
// For some reason ClassNode.getAbstractMethods() has a problem - ClassNode.superclass is null.
return null
}

This used to work with groovy 1.5.4: after the call of createTreeNode method the groovy core class "ClassNode" sometime threw a GroovyBugError and it was possible to catch this exception.

After changing to 1.6 the exception that is thrown is not a GroovyBugError anymore, it is a InvokerInvocationException that wraps (cause field) around the GroovyBugError and therefore doesen't get caught anymore.



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Reto Kleeb - 07/Mar/08 11:29 AM
try {
	return TreeNodeFactory.createTreeNode(this, value."${method.name}"(), name)
} catch (org.codehaus.groovy.GroovyBugError e) {
	// Some getters are not for us.
	return null
} catch (NullPointerException e) {
	// For some reason ClassNode.getAbstractMethods() has a problem - ClassNode.superclass is null.
	return null
}

sorry...code looks nicer like this


Alex Tkachman - 17/Mar/08 05:51 AM
Unfortunately I am not able to reproduce.
Groovy2666Bug.groovy is test, I tried. Please advice what to change.

Reto Kleeb - 17/Mar/08 06:44 AM
hm...we did some further investigation and well....this whole thing is kind of strange:
  • We can only reproduce this behavior in Eclipse using Groovy-Eclipse with a 1.6 groovy-core (which is what we're using for our refactoring project)

This version of the plugin is available from http://sifsstud4.hsr.ch/GroovyRefactoring/updateSite/releases/

The problem is obviously related to a certain situation while using groovy from eclipse. Our temporary solution was to catch the InvokerInvocationException and then check for the cause of this Exception. But as I said, we're a little puzzled, maybe someone from the groovy-eclipse team has an idea, Jochen Theodorou said that the problem sounds familiar: http://archive.groovy.codehaus.org/eclipse-plugin-dev/47D14FA4.5030406%40gmx.org