On 17/12/2012, at 10:35 PM, Daz DeBoer wrote:
> G'day
> I've made some minor changes to the way build failures are reported,
> so that more context is included in the "What went wrong:" section of
> the build failure report.
>
> Entry point selection
> ----------------------------
> Choosing a 'top-level' exception to report has not changed. As before,
> we first find the "entry point" exception in the failure chain. This
> is usually a GradleScriptException or TaskExecutionException, but in
> some cases could be the 'deepest' exception marked with @Contextual.
>
> Failure summary
> -----------------------
> Previously, we would simply report the entry point, it's direct cause,
> and recursively report the nested cause for any exception that was
> marked as @Contextual. So having a single non-contextual exception in
> the chain meant that any 'deeper' contextual exceptions would not be
> reported.
>
> The way it now work is:
> 1) Report the entry point
> 2) Descend the chain, reporting any exception(s) marked with @Contextual
> 3) Report the direct cause of the last reportable exception. This will
> be the direct cause of the 'deepest' @Contextual exception, or the
> direct cause of the entry point.
>
> In practice this means that all @Contextual exceptions in the chain
> will be reported, even if interspersed with non-contextual exceptions.
> This makes reporting meaningful when using ActionBroadcast or other
> similar infrastructure that may wrap the real exception. Previously
> the ultimate cause was not reported in this case.
>
> UserCodeAction
> -----------------------
> When a user supplies code that we execute as an Action, you can now
> wrap the user-supplied action in a UserCodeAction. This simply wraps
> any exception (often emitted by Groovy) in a UserCodeException, which
> is given a sensible message and is marked @Contextual.
Do we want to automate this in the class generation?
e.g.
@UserAction("this is the error message")
void withXml(Action<T> action) {
}
And have something like the following generated…
void withXml(Action<T> action) {
super.withXml(new UserCodeAction<T>("this is the error message",
action))
}
>
> An example of this in action is the maven.pom.withXml() hook in the
> new 'maven-publish' plugin. Bad user code will now be reported like:
>
> Execution failed for task ':publishMavenPublicationToMavenRepository'. (1)
>> Failed to publish publication 'maven' to repository 'maven' (2)
>> Failed to notify action. (3)
>> Could not apply withXml() to generated POM (4)
>> No such property: foo for class: groovy.util.Node (5)
>
> 1) the TaskExecutionException
> 2) the first @contextual exception
> 3) the "Failed to notify action" shouldn't really be there. It is
> included because ListenerNotifyException is @Contextual, but it
> doesn't really provide any failure context. I plan to remove this
> annotation.
> 4) the UserCodeException message. This is the deepest @Contextual exception
> 5) The Groovy exception caught and wrapped by the UserCodeAction
>
> I hope this makes exception reporting a bit more understandable.
> cheers
> Daz
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
