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

Details

Description

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.

Issue Links

relates to

Bug - A problem which impairs or prevents the functions of the product. GROOVY-2643 Delegate property is ignored by closure

  • Blocker - Blocks development and/or testing work, production could not run
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Reto Kleeb added a comment - 
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

Show
Reto Kleeb added a comment - 
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
Hide
Permalink
Alex Tkachman added a comment -

Unfortunately I am not able to reproduce.
Groovy2666Bug.groovy is test, I tried. Please advice what to change.

Show
Alex Tkachman added a comment - Unfortunately I am not able to reproduce. Groovy2666Bug.groovy is test, I tried. Please advice what to change.
Hide
Permalink
Reto Kleeb added a comment -

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

Show
Reto Kleeb added a comment - 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

People

  • Assignee:
    Alex Tkachman
    Reporter:
    Reto Kleeb
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: