java - Thrift 异常中的异常消息是如何工作的？

Question

我保存了 IDL 文件，你可以定义你自己的服务方法可能抛出的异常类型:

exception SampleException {
    1: list<string> failed
}

在日志中看到正确的异常消息的契约是什么？我见过这样的日志消息:foo.bar.Service 中未处理的异常
my.package.SomeException: null。我猜它在哪里说 null 这应该是异常消息？

不幸的是，异常(exception)情况并没有得到很好的记录。我应该添加一个 string message 字段来让它工作吗？是否有任何其他转换，如字段名称？

Answer 1

节俭异常(exception)(一般)

Whats the contract for seeing a proper exception message in the logs?

没有契约(Contract)定义如何将消息写入任何日志。 Thrift 被设计为与协议(protocol)无关和与传输无关。例如，如果你构建的 HTTP 服务器在他的日志文件中写入了一些东西，这完全不在 Thrift 之内，它只与你的 HTTP 服务器有关。

Should I be adding a string message field for that to work? Is there any other convention like name of the field?

没有，除了您选择的语言可能强加的内容外，没有约定或限制。从技术上讲，exception 就像一个 struct。例如，以下 IDL 取自 ThriftTest.thrift文件。

exception Xception2 {
  1: i32 errorCode,
  2: Xtruct struct_thing
}

上面使用的Xtruct 是嵌套在异常中的另一个struct。你看，你几乎可以用 Thrift 异常做任何事情，这对结构也是可能的。这使您能够向客户端发送丰富的错误信息，而不仅仅是“服务器上发生了一些丑陋的事情”之类的字符串。

struct 的区别在于系统如何处理它们:异常在服务器上序列化，然后在客户端重新引发。意外异常是

• 作为通用TApplicationException 被捕获并重新抛出
• 或者根本没被抓到

后一种行为在某种程度上依赖于语言，现在即将从“未捕获”慢慢改变为“作为通用 TApplicationException 重新抛出”方向。

Unfortunately exceptions are not very well documented

这就是Thrift Whitepaper不得不说的异常(exception):

2.4 Exceptions

Exceptions are syntactically and functionally equivalent to structs except that they are declared using the exception keyword instead of the struct keyword.

The generated objects inherit from an exception base class as appropriate in each target programming language, in order to seamlessly integrate with native exception handling in any given language. Again, the design emphasis is on making the code familiar to the application developer.

如何确保 Exception(string) CTOR 被调用？

I have seen log messages like this:

Unhandled exception in foo.bar.Service my.package.SomeException: null 

I guess where it says null this should be the exception message? [...] for defined exceptions that get generated to Scala/Java, what is the proper way to make sure this constructor is called: public Exception(String message).

看起来很像“从不”，或者更准确地说是“不可能”。这些是 Thrift(主干版本)从上面的 IDL 生成的所有 CTOR:

  public Xception() {
  }

  public Xception(
    int errorCode,
    String message)
  {
    this();
    this.errorCode = errorCode;
    setErrorCodeIsSet(true);
    this.message = message;
  }

  /**
   * Performs a deep copy on <i>other</i>.
   */
  public Xception(Xception other) {
    __isset_bitfield = other.__isset_bitfield;
    this.errorCode = other.errorCode;
    if (other.isSetMessage()) {
      this.message = other.message;
    }
  }

由于所有生成的异常都源自 TException，因此它们必须调用参数化 CTOR 之一来获取 message 和/或 cause到 Exception 基础。但是Xception显然不会这样做。原因可能是 Thrift 允许您将任何东西定义为异常成员，并且不保证(或假设)任何东西。换句话说，不能确定在异常处甚至有一个字段。因此，您总是以 null 错误消息结束。

底线(有点像 TL;DR)

我认为，一般来说你是对的，this behaviour should be changed .目前，我看到的唯一解决方法是在它们进入日志之前显式捕获 TException 并使用 toString() 成员函数重新打包它们:

} catch (org.apache.thrift.TException te) {
  throw new Exception(te.toString());
}