Bug: gradle swallows Exceptions in init script


(Thibault Kruse) #1

To reproduce:

create build.gradle:

apply plugin: "java"

create init.gradle:

useLogger(new CustomEventLogger())
  class CustomEventLogger extends BuildAdapter implements TaskExecutionListener {
      public void beforeExecute(Task task) {
        println "foo"
        throw new RuntimeException("foo")
        println("bar")
    }
      public void afterExecute(Task task, TaskState state) {
        println()
    }
      public void buildFinished(BuildResult result) {
        println 'build completed'
    }
}

Produces: $ gradle build -I init.gradle

foo build completed

Should produce: Some sign of exception happening

Even --stacktrace and --debug do not show exception

Seen on gradle 1.9 and 1.11


(Thibault Kruse) #2

Ah, sorry. Should be more specific. Using a custom Logger swallows all Exception reporting.

The code uses the example from http://www.gradle.org/docs/current/userguide/logging.html

Maybe there is a better way to do custom logging without swallowing Exceptions.


(Thibault Kruse) #3

And to be even more specific, this happens if the Listener passed to useLogger() implements BuildListener.

So at least I suggest quickly removing BuildAdapter from the example in the docs along with the buildFinished() method. Then the example works to start with.


(Thibault Kruse) #4

Also, BTW: What I wanted to do was to add logging of the time the tasks finished, to get an idea of why my builds on Jenkins take so long. However, I also do not want to loose the standard gradle outputs like SKIPPED, UP-TO-DATE, and so on, and I do not wish to reimplement the logging.

Would be nice if the documentation example rather showed how to do that, how to extend TaskExecutionLogger in a viable way maybe.


(Luke Daley) #5

Hi Thibault,

I’m just about to start looking into this, but quickly I just wanted to point out: http://www.gradle.org/docs/current/userguide/tutorial_gradle_command_line.html#sec:profiling_build


(Luke Daley) #6

Hi Thibault,

I read through those docs and I think they are accurate. The first sentence of the code example you linked to says: “You can replace much of Gradle’s logging UI with your own”. This feature is not designed to be used to extend Gradle’s logging, but rather replace it.

If you want to extend the logging you would just add the listener via ‘addListener()’ and not ‘useLogger()’.


(Thibault Kruse) #7

Hi Luke,

I can add a Listener using addListener() instead to solve my problem, thanks. ‘–profile’ is nice, but I did not find any nice jenkins integration, and I would like the information to be available in the log output. I guess I could parse the --profile output file if it exist and print that…

The logging documentation may be accurate, but it is still not helpful. It tempts users to modify their buildsystem to swallow exceptions without giving fair warning. At least the example could check the taskState in afterExecute and print a stacktrace on Exception.

regards,

Thibault


(Luke Daley) #8

At least the example could check the taskState in afterExecute and print a stacktrace on Exception.

That’s a good idea. I’ll make that change. Thanks.