Improve exception handling

(detelinyordanov) #1

Hi guys,

I’m new to both Gradle and Groovy but have been working with them for a couple of months so far. I’m also new to scripting languages and have experienced a number of pitfalls while writing Gradle plugins and tasks. It seems that Groovy Eclipse plugin is not reporting all the warnings/errors in the script as Eclipse JDT does (or it might be the case that I have not configured it properly). However, I think that Gradle could improve a bit its exception handling since from time to time I get those “Build aborted because of an unexpected internal error” messages which are very hard to investigate because even with the --stacktrace option there is no exception printed.

Here is one example that demonstrates the most common problem I have experienced during my learning phase:

class BrokenTask extends DefaultTask {
 String destination
    public BrokenTask() { }
 public File getDestination() { return destination }
  class BrokenPlugin implements Plugin<Project> {
   def void apply(final Project project) {
  BrokenTask task = project.tasks.add('brokenTask', BrokenTask)
      task.conventionMapping.destination = { "$project.buildDir/broken" }
  apply plugin: BrokenPlugin
  defaultTasks 'brokenTask'

In the above example the getDestination() method is defined to return a File while the property is defined as a String.

Running this reports the mentioned internal error message without any stacktrace. Debugging it shows that the original exception is caught by Gradle’s launcher:

java.lang.ClassCastException: org.codehaus.groovy.runtime.GStringImpl cannot be cast to

However it seems that DefaultExceptionAnalyser#findDeepest returns null instead of the original exception.

I’m currently using Gradle 1.0-m3 but checked the trunk and the above method still does same thing.

I guess I could write a custom build listener, however it would be great if this is fixed in Gradle.



(Luke Daley) #2

If you run with --full-stacktrace do you see the stack?

(detelinyordanov) #3

Nope :frowning:

I just tried adding a custom BuildListener but saw that the DefaultExceptionAnalyser.transform(t) which is throwing away the original exception is called before creating the BuildResult passed to the listener, so even this is not an option.