Gradle任务生命周期概览
理解gradle的构建生命周期对于正确处理任务中的逻辑至关重要。gradle构建主要分为三个阶段：
- 初始化阶段 (Initialization Phase)： 确定哪些项目参与构建，并为每个项目创建Project实例。
- 配置阶段 (Configuration Phase)： 构建脚本被执行，所有项目和任务都被配置。在这个阶段，任务被定义，它们的属性被设置，并且构建图被构建。
- 执行阶段 (Execution Phase)： 根据配置阶段生成的构建图，Gradle执行被请求的任务及其所有依赖任务。
关键在于，任何直接写在任务定义块（task('myTask', type: MyTaskType) { ... }）中的代码，都会在配置阶段执行。而任务实际要执行的操作，则需要在特殊的执行块中定义。
错误的异常处理方式及其影响
考虑以下Gradle任务定义，它尝试在任务定义块中直接检查一个目录是否存在，如果不存在则抛出GradleException：
task('myRandomTask', type: Zip) {
// 这里的代码在配置阶段执行
if(!(new File("$projectDir/../../some-other-dir/")).exists()) {
throw new GradleException("dependent dir not kept at relative path");
}
// do my stuff
}当您运行./gradlew build时，即使build任务与myRandomTask任务之间没有直接依赖关系，整个构建也可能失败。这是因为if条件检查和throw new GradleException(...)语句在myRandomTask的配置阶段执行。如果条件不满足，Gradle会在尝试完成所有任务的配置之前就抛出异常，从而中断整个构建过程。这导致了不必要的全局构建失败，影响了其他不相关的任务。
正确的异常处理实践：doLast与doFirst
为了确保异常只在特定任务被执行时才触发，您需要将条件检查和异常抛出逻辑放置在任务的执行块中。Gradle提供了doLast和doFirst块来定义任务在执行阶段要执行的操作：
- doFirst { ... }： 在任务的任何其他操作之前执行。
- doLast { ... }： 在任务的所有其他操作之后执行。
将上述示例中的异常逻辑移至doLast块，可以得到以下正确的实现方式：
task('myRandomTask', type: Zip) {
// 任务的配置，例如设置源文件、目标目录等
// do my stuff (configuration related)
// 这里的代码在任务的执行阶段，且在其他动作之后执行
doLast {
if(!(new File("$projectDir/../../some-other-dir/")).exists()) {
throw new GradleException("dependent dir not kept at relative path");
}
}
}通过这种方式，if条件检查和GradleException只会在myRandomTask任务被实际选中并执行时才运行。如果./gradlew build命令执行时，myRandomTask不是build任务的依赖，那么myRandomTask将不会被执行，其doLast块中的异常逻辑也不会被触发，从而避免了对整个构建的干扰。
核心原则与最佳实践
- 区分配置与执行逻辑： 任何需要运行时检查、文件操作、网络请求等可能导致构建失败的操作，都应放置在doFirst或doLast块中。任务定义块应主要用于声明任务的属性和配置。
- 使用GradleException： 当您需要在Gradle任务中明确指示构建失败时，抛出GradleException是推荐的做法。它会被Gradle构建系统识别并妥善处理，提供清晰的错误信息。
- 保持任务独立性： 确保一个任务的内部逻辑不会无意中破坏不相关的构建部分。通过将运行时检查封装在执行块中，可以提高构建的健壮性和模块化程度。
- 提供清晰的错误信息： 异常消息应简洁明了，提供足够的信息帮助用户理解问题所在，例如哪个目录缺失、为什么缺失等。
总结
正确处理Gradle任务中的异常对于维护构建的稳定性和可预测性至关重要。核心原则在于理解Gradle的配置和执行阶段，并将运行时检查和可能抛出异常的代码逻辑放置在doFirst或doLast执行块中。这样做可以确保异常仅在特定任务被执行时才触发，避免在配置阶段导致整个构建意外失败，从而构建出更加健壮和高效的Gradle项目。
