groovy

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

Details

  • Number of attachments :
    0

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: