Java：使用 RuntimeException 来逃避访问者

Question

我非常想在 Java 程序中使用未经检查的异常作为短路控制流构造。 我希望这里有人能建议我更好、更干净的方法来处理这个问题。

我的想法是，我想缩短访问者对子树的递归探索，而不必在每个方法调用中检查“停止”标志。 具体来说，我正在使用抽象语法树上的访问者构建控制流图。 AST 中的 return 语句应停止探索子树并将访问者发送回最近的封闭 if/then 或循环块。

Visitor 超类（来自 XTC 库）定义了

Object dispatch(Node n)

哪些回调通过dispatch形式的反射方法

Object visitNodeSubtype(Node n)

没有声明抛出任何异常，所以我声明了一个扩展RuntimeException的私有类

private static class ReturnException extends RuntimeException {
}

现在，return语句的访问者方法看起来像

Object visitReturnStatement(Node n) {
    // handle return value assignment...
    // add flow edge to exit node...
    throw new ReturnException();
}

和每个复合语句都需要处理 ReturnException

Object visitIfElseStatement(Node n) {
  Node test = n.getChild(0);
  Node ifPart = n.getChild(1);
  Node elsePart = n.getChild(2);

  // add flow edges to if/else... 

  try{ dispatch(ifPart); } catch( ReturnException e ) { }
  try{ dispatch(elsePart); } catch( ReturnException e ) { }
}

这一切都很好，除了：

1. 我可能忘记在某处捕获 ReturnException 并且编译器不会警告我。
2. 我感觉很脏。

有一个更好的方法吗？ 是否有我不知道的 Java 模式来实现这种非本地控制流？

[更新] 这个特定的示例有些无效：Visitor 超类捕获并包装异常（甚至是 RuntimeException），因此抛出异常并没有真正的帮助。 我已经实现了从 visitReturnStatement 返回 enum 类型的建议。 幸运的是，这只需要在少数地方进行检查（例如，visitCompoundStatement），因此实际上比抛出异常要少一些麻烦。

总的来说，我认为这仍然是一个有效的问题。 不过，如果您没有依赖第三方库，那么整个问题可以通过合理的设计来避免。

Answer 1

我认为这是一种合理的方法，原因如下：

• 您正在使用第 3 方，并且无法添加已检查的异常
• 在大量访问者中到处检查返回值，而仅在少数情况下才需要这样做，这是不必要的负担

此外，还有那些认为未经检查的异常并不是那么糟糕的人 。 你的用法让我想起了 Eclipse 的 OperationCanceledException 用于退出长时间运行的后台任务。

它并不完美，但是，如果有详细记录，对我来说似乎没问题。

Answer 2

抛出运行时异常作为控制逻辑绝对是一个坏主意。 你感觉肮脏的原因是你绕过了类型系统，即你的方法的返回类型是一个谎言。

您有多种更加干净的选择。

1. Exceptions Functor 是

一个很好的技术，当你受限于你可能抛出的异常时，如果你不能抛出一个受检查的异常，就返回一个将抛出一个受检查的异常的对象。 例如，java.util.concurrent.Callable 就是该函子的一个实例。

请参阅此处了解此技术的详细说明。

例如，而不是这个：

public Something visit(Node n) {
  if (n.someting())
     return new Something();
  else
     throw new Error("Remember to catch me!");
}

这样做：

public Callable<Something> visit(final Node n) {
  return new Callable<Something>() {
    public Something call() throws Exception {
      if (n.something())
         return new Something();
      else
         throw new Exception("Unforgettable!");
    }
  };
}

2。 不相交联合（又名“Either Bifunctor”）

此技术允许您从同一方法返回两种不同类型之一。 它有点像大多数人熟悉的 Tuple 技术，用于从方法返回多个值。 但是，这不是返回 A 类型和 B 类型的值，而是返回 A 类型或 B 类型的单个值。

例如，给定一个枚举 Fail，它可以枚举适用的错误代码，该示例将变为

public Either<Fail, Something> visit(final Node n) {
  if (n.something())
    return Either.<Fail, Something>right(new Something());
  else
    return Either.<Fail, Something>left(Fail.DONE);
}

...现在更加清晰，因为您不需要 try/catch：

Either<Fail, Something> x = node.dispatch(visitor);
for (Something s : x.rightProjection()) {
  // Do something with Something
}
for (Fail f : x.leftProjection()) {
  // Handle failure
}

Either 类并不是很难编写，但是 是一个功能齐全的实现由Functional Java 库提供。

3. Option Monad

有点像类型安全的 null，当您不想为某些输入返回值，但不需要异常或错误代码时，这是一个很好的技术。 通常，人们会返回所谓的“哨兵值”，但 Option 相当干净。

现在你已经......

public Option<Something> visit(final Node n) {
  if (n.something())
    return Option.some(new Something());
  else
    return Option.<Something>none();
}    

这个调用很好而且干净：

Option<Something> s = node.dispatch(visitor));
if (s.isSome()) {
  Something x = s.some();
  // Do something with x.
}
else {
  // Handle None.
}

事实上它是一个 monad让您可以链接调用而不处理特殊的 None 值：

public Option<Something> visit(final Node n) {
  return dispatch(getIfPart(n).orElse(dispatch(getElsePart(n)));
}    

Option 类比 Either 更容易编写，但同样，一个全功能的实现由Functional Java 库提供。

请参阅此处了解 Option 和 Either 的详细讨论。

Answer 3

您不只是返回一个值有什么原因吗？ 比如NULL，如果你真的想什么也不返回？ 这会简单得多，并且不会冒抛出未经检查的运行时异常的风险。

Answer 4

我看到了以下选项：

1. 继续定义 RuntimeException 子类。 通过在最常见的 dispatch 调用中捕获异常来检查是否存在严重问题，并在出现问题时报告该异常。
2. 如果节点处理代码认为搜索应该突然结束，则让其返回一个特殊对象。 这仍然迫使您检查返回值而不是捕获异常，但您可能更喜欢这种方式的代码外观。
3. 如果树遍历要被某些外部因素停止，请在子线程中完成所有操作，并在该对象中设置同步字段，以便告诉线程提前停止。

Answer 5

为什么要从访问者那里返回值？ 访问者的适当方法由正在访问的类调用。 完成的所有工作都封装在访问者类本身中，它应该不返回任何内容并处理它自己的错误。 调用类所需的唯一义务是调用适当的visitXXX方法，仅此而已。 （这假设您在示例中使用重载方法，而不是为每种类型覆盖相同的访问（）方法）。

访问者不应更改所访问的类，或者必须了解其用途，除非它允许访问发生。 返回值或引发异常将违反此规定。

访客模式

Answer 6

您必须使用 XTC 的访客吗？ 这是一个非常简单的接口，您可以实现自己的接口，它可以抛出 checked ReturnException，您不会忘记在需要的地方捕获它。

Answer 7

我没有使用过你提到的 XTC 库。 它如何提供访问者模式的补充部分 - 节点上的 accept(visitor) 方法？ 即使这是一个基于反射的调度程序，仍然必须有一些东西可以处理语法树上的递归？

如果这个结构迭代代码很容易访问，并且您还没有使用 visitXxx(node) 方法的返回值，那么您是否可以利用一个简单的枚举返回值，甚至一个布尔标志，告诉accept(visitor) 不递归到子节点？

如果：

• accept(visitor) 未由节点显式实现（存在某些字段或访问器反射，或者节点只是为某些标准控制流逻辑实现子获取接口，或出于任何其他原因...），并且

• 您不想弄乱库的结构迭代部分，或者它不可用，或者不值得努力...

那么作为最后的手段，我想例外可能是您的仍然使用普通 XTC 库的唯一选择。

不过，这是一个有趣的问题，我可以理解为什么基于异常的控制流让你感觉很肮脏......