On 03/01/2013, at 5:05 AM, Luke Daley wrote:
>
> 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))
> }
Not just yet. I don't think UserCodeAction really worked out:
- You need to construct the error message before invoking the action, which
means you can't have the error message reflect anything about what went wrong.
- It assumes all actions are user actions, which isn't always the case, for
example when our plugins use the entry point.
I don't think we need to do anything about this just yet, but I'd rather reuse
the 'blame' stuff that we use to decide where a failure occurred, to also
decide whether a failure happened in 'user' code or not, and do this as part of
the exception analysis rather than mixing this into all the places where user
code may be executed.
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
