本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 错误处理
**Topics**
+ [TryCatchFinally 语义学](#errorhandling.trycatchfinally)
+ [取消](#test.cancellation.resources)
+ [嵌套 TryCatchFinally](#errorhandling.nested)
Java 中的 `try`/`catch`/`finally` 结构使得错误处理变得轻松，并且可普遍使用。这使您能够将错误处理程序关联到代码块。在内部，这是通过在调用堆栈上填充有关错误处理程序的附加元数据来实现的。当引发异常时，运行时会查看已关联错误处理程序的调用堆栈并调用它；如果未找到相应的错误处理程序，它会在调用链中向上传播异常。
这对于同步代码很有效，但处理异步和分布式程序中的错误会带来额外的挑战。由于异步调用会立即返回，因此当异步代码执行时，调用者不在调用堆栈中。这意味着，调用方无法通过常规方式处理异步代码中的未处理异常。通常，通过将错误状态传递给回调 (该回调将传递给异步方法) 来处理源自异步代码的异常。或者，如果正在使用 `Future`，它会在您尝试访问它时报告错误。这并不理想，因为接收异常的代码 (使用 `Future` 的回调或代码) 没有原始调用的上下文，并且可能无法充分处理异常。此外，在分布式异步系统中，当组件同时运行时，可能会同时出现多个错误。这些错误的类型和严重性可能不同，并且需要适当处理。
在异步调用之后清除资源也很困难。与同步代码不同，你不能在调用代码try/catch/finally中使用来清理资源，因为当 finally 块执行时，在 try 块中启动的工作可能仍在进行中。
该框架提供了一种机制，使分布式异步代码中的错误处理与 Java 类似，而且几乎同样简单try/catch/finally。
```
ImageProcessingActivitiesClient activitiesClient
= new ImageProcessingActivitiesClientImpl();
public void createThumbnail(final String webPageUrl) {
new TryCatchFinally() {
@Override
protected void doTry() throws Throwable {
List images = getImageUrls(webPageUrl);
for (String image: images) {
Promise localImage
= activitiesClient.downloadImage(image);
Promise thumbnailFile
= activitiesClient.createThumbnail(localImage);
activitiesClient.uploadImage(thumbnailFile);
}
}
@Override
protected void doCatch(Throwable e) throws Throwable {
// Handle exception and rethrow failures
LoggingActivitiesClient logClient = new LoggingActivitiesClientImpl();
logClient.reportError(e);
throw new RuntimeException("Failed to process images", e);
}
@Override
protected void doFinally() throws Throwable {
activitiesClient.cleanUp();
}
};
}
```
`TryCatchFinally` 类及其变体 (`TryFinally` 和 `TryCatch`) 与 Java 的 `try`/`catch`/`finally` 的工作方式类似。通过使用它，您可以将异常处理程序关联到可作为异步和远程任务执行的工作流程代码块。`doTry()` 方法在逻辑上等同于 `try` 块。此框架自动执行 `doTry()` 中的代码。`Promise` 对象列表可传递给 `TryCatchFinally` 的构造函数。当已传入构造函数的所有 `Promise `对象就绪时，将执行 `doTry` 方法。如果已从 `doTry()` 中异步调用的代码引发了异常，则将取消 `doTry()` 中的任何待处理工作，并且将调用 `doCatch()` 以处理异常。例如，在上述列出内容中，如果 `downloadImage` 引发异常，则将取消 `createThumbnail` 和 `uploadImage`。最后，在完成所有异步工作 (完成、失败或取消) 时，将调用 `doFinally()`。它可用于清除资源。您也可以嵌套这些类来满足您的需求。
在 `doCatch()` 中报告异常时，框架将提供一个包含异步调用和远程调用的完整逻辑调用堆栈。这在调试时很有用，特别是在您具有调用其他异步方法的异步方法时。例如，来自 downloadImage 的异常将生成与以下内容类似的异常：
```
RuntimeException: error downloading image
at downloadImage(Main.java:35)
at ---continuation---.(repeated:1)
at errorHandlingAsync$1.doTry(Main.java:24)
at ---continuation---.(repeated:1)
…
```
## TryCatchFinally 语义学
for Java 程序的执行可以可视化 AWS Flow Framework 为一棵由同时执行的分支组成的树。调用异步方法、活动和 `TryCatchFinally` 本身将在此执行树中创建一个新的分支。例如，可以按照下图中显示的树的形式来查看图像处理工作流程。
一个执行分支中的错误将导致该分支展开，就像异常导致 Java 程序中的调用堆栈展开一样。展开会继续将执行分支上移，直到错误被处理或到达树的根，在这种情况下，工作流程执行将被终止。
框架将处理任务时发生的错误报告为异常。它将 `TryCatchFinally` 中定义的异常处理程序 (`doCatch()` 方法) 与相应的 `doTry()` 中的代码所创建的所有任务关联。如果任务失败（例如，由于超时或未处理异常），则会引发相应的异常，并调用相应的 `doCatch()` 进行处理。为此，框架与 Amazon SWF 协同工作，传播远程错误，并在调用方的上下文中将其恢复为异常。
## 取消
当同步代码中出现异常时，控制将直接跳至 `catch` 块，并跳过 `try` 块中的任何剩余代码。例如：
```
try {
a();
b();
c();
}
catch (Exception e) {
e.printStackTrace();
}
```
在此代码中，如果 `b()` 引发异常，则绝不会调用 `c()`。将其与工作流程进行比较：
```
new TryCatch() {
@Override
protected void doTry() throws Throwable {
activityA();
activityB();
activityC();
}
@Override
protected void doCatch(Throwable e) throws Throwable {
e.printStackTrace();
}
};
```
在此示例中，对 `activityA`、`activityB` 和 `activityC` 的调用全部成功返回，并导致创建将异步执行的三个任务。假定 `activityB` 的任务稍后将导致错误。Amazon SWF 会将此错误记录在历史记录中。要处理此错误，框架首先会尝试取消源自相同的 `doTry()` 范围的所有其他任务；在此示例中，为 `activityA` 和 `activityC`。当所有此类任务完成 (取消、失败或成功完成) 时，将调用相应的 `doCatch()` 方法以处理错误。
与同步示例不同，其中绝不会执行 `c()`，已调用 `activityC`，并且已计划执行一个任务；因此，框架将尝试取消它，但不能保证将其取消。不能保证取消，因为活动可能已完成、可能忽略取消请求或可能因错误而导致失败。不过，框架保证仅在完成从相应的 `doTry()` 启动的所有任务后，才调用 `doCatch()`。它还保证仅在完成从 `doTry()` 和 `doCatch()` 启动的所有任务后，才调用 `doFinally()`。例如，如果上述示例中的活动相互依赖，假设 `activityB` 依赖 `activityA`，`activityC` 依赖 `activityB`，那么 `activityC` 将被立即取消，因为在 `activityB` 完成之前，Amazon SWF 不会对其进行安排：
```
new TryCatch() {
@Override
protected void doTry() throws Throwable {
Promise a = activityA();
Promise b = activityB(a);
activityC(b);
}
@Override
protected void doCatch(Throwable e) throws Throwable {
e.printStackTrace();
}
};
```
### 活动检测信号
f AWS Flow Framework or Java 的协作取消机制允许优雅地取消飞行中的活动任务。在触发取消时，将自动取消已被阻止或正在等待分配给工作线程的任务。不过，如果已将任务分配给工作线程，则框架将请求取消活动。您的活动实施必须明确处理此类取消请求。通过报告活动的检测信号来做到这一点。
报告检测信号将允许活动实施报告进行中的活动任务的进度，这对于监控很有用，并且它允许活动检查取消请求。如果已请求取消，则 `recordActivityHeartbeat` 方法将引发 `CancellationException`。活动实施可以捕获此异常并对取消请求进行操作，也可以通过承受异常来忽略请求。为了满足取消请求，活动应该执行所需的清除 (如果有)，然后重新引发 `CancellationException`。在从活动实施中引发此异常时，框架会将已完成的活动任务记录为取消状态。
以下示例显示了一个下载和处理映像的活动。在处理每个映像后，它会发出检测信号；如果请求取消，它会执行清除操作并重新引发异常以确认取消。
```
@Override
public void processImages(List urls) {
int imageCounter = 0;
for (String url: urls) {
imageCounter++;
Image image = download(url);
process(image);
try {
ActivityExecutionContext context
= contextProvider.getActivityExecutionContext();
context.recordActivityHeartbeat(Integer.toString(imageCounter));
} catch(CancellationException ex) {
cleanDownloadFolder();
throw ex;
}
}
}
```
虽然不要求报告活动检测信号，但如果您的活动是长期运行的或是您希望在错误情形下取消的开销较大的操作，则建议这样做。您应定期从活动实施中调用 `heartbeatActivityTask`。
如果活动超时，则将引发 `ActivityTaskTimedOutException`，并且异常对象上的 `getDetails` 将返回已传递给上次对相应活动任务的 `heartbeatActivityTask` 的成功调用的数据。工作流程实施可以使用此信息来确定活动任务超时前的进度。
**注意**
检测信号过于频繁不是好的做法，因为 Amazon SWF 可能会限制检测信号请求。有关 Amazon SWF 设置的限制，请参阅 [Amazon Simple Workflow Service Developer Guide](https://docs.aws.amazon.com/amazonswf/latest/developerguide/)。
### 明确取消任务
除了错误情形之外，还存在其他您可能会明确取消任务的情况。例如，如果用户取消订单，则可能需要取消使用信用卡处理付款的活动。框架允许您明确取消在 `TryCatchFinally` 范围内创建的任务。在以下示例中，如果在处理付款时收到信号，则付款任务将被取消。
```
public class OrderProcessorImpl implements OrderProcessor {
private PaymentProcessorClientFactory factory
= new PaymentProcessorClientFactoryImpl();
boolean processingPayment = false;
private TryCatchFinally paymentTask = null;
@Override
public void processOrder(int orderId, final float amount) {
paymentTask = new TryCatchFinally() {
@Override
protected void doTry() throws Throwable {
processingPayment = true;
PaymentProcessorClient paymentClient = factory.getClient();
paymentClient.processPayment(amount);
}
@Override
protected void doCatch(Throwable e) throws Throwable {
if (e instanceof CancellationException) {
paymentClient.log("Payment canceled.");
} else {
throw e;
}
}
@Override
protected void doFinally() throws Throwable {
processingPayment = false;
}
};
}
@Override
public void cancelPayment() {
if (processingPayment) {
paymentTask.cancel(null);
}
}
}
```
### 接收取消任务的通知
当任务在取消状态下完成时，框架通过引发 `CancellationException` 来将此情况告知工作流程逻辑。当活动在取消状态下完成时，将在历史记录中生成一条记录，框架将调用相应的 `doCatch()`，并引发 `CancellationException`。如上一个示例中所示，当取消付款处理任务时，工作流程将收到 `CancellationException`。
未处理的 `CancellationException` 会在执行分支中向上传播，就像任何其他异常一样。不过，`doCatch()` 方法仅在范围中没有任何其他异常时收到 `CancellationException`；其他异常的优先级高于取消异常的优先级。
## 嵌套 TryCatchFinally
您可以嵌套 `TryCatchFinally` 以满足您的需求。由于每个分支都会在执行树中`TryCatchFinally`创建一个新的分支，因此您可以创建嵌套作用域。父范围中的异常将导致尝试取消嵌套的 `TryCatchFinally` 在其中启动的所有任务。不过，嵌套的 `TryCatchFinally` 中的异常不会自动传播到父级。如果您希望将嵌套的 `TryCatchFinally` 中的异常传播到其包含的 `TryCatchFinally`，则应在 `doCatch()` 中重新引发该异常。换句话说，仅提供未处理的异常，就像 Java 的 `try`/`catch` 一样。如果您通过调用取消方法来取消嵌套的 `TryCatchFinally`，则将取消嵌套的 `TryCatchFinally`，但不会自动取消包含的 `TryCatchFinally`。
```
new TryCatch() {
@Override
protected void doTry() throws Throwable {
activityA();
new TryCatch() {
@Override
protected void doTry() throws Throwable {
activityB();
}
@Override
protected void doCatch(Throwable e) throws Throwable {
reportError(e);
}
};
activityC();
}
@Override
protected void doCatch(Throwable e) throws Throwable {
reportError(e);
}
};
```