什么是 http 500 响应的 Thrift 等价物？

Question

我正在使用 C# 试验 Thrift 服务。使用 REST 服务，未捕获的异常将由 Web 框架转换为 HTTP 500 响应代码。

据我所知，使用 thrift，我需要在我的 thrift 文件中声明所有可能的异常类型。这给我留下了两个我能想到的选择：

1. 声明一个 InternalServerError 类型并将其添加到每个方法中。每个处理程序方法都需要捕获未处理的异常并重新抛出我的特殊类型。
2. 让客户端体验这种情况下的默认行为，似乎是套接字意外关闭。

第一个选项会起作用，但对于看起来很常见的情况来说，这似乎是相当多的变通办法。我注意到在内部使用了一个 TApplicationException ，它似乎可以很好地工作，但我似乎无法在我的 thrift 文件中使用它，所以这不起作用。

thrift 用户在服务器端处理未捕获异常的惯用方式是什么？

Answer 1

HTTP 500

使用 REST 服务，Web 框架会将未捕获的异常转换为 HTTP 500 响应代码。

这是“让服务器调用在未捕获的异常上惨败”的委婉说法。 REST 框架遵循这些策略，因为 REST 是围绕 HTTP 动词、响应和行为特意设计的。所以反过来说：HTTP 状态码不会以某种方式添加到 REST 实现中，它们是 REST 的基本原则。

惯用的异常处理

thrift 用户在服务器端处理未捕获异常的惯用方式是什么？

简短的回答：你不想那样。

如果运气好的话，未捕获的异常会转换为通用的 TApplication 异常，但它们也可能会捕获诸如意外关闭的传输之类的影响，正如您已经观察到的那样。显然，缺点是，您丢失了您可能想要传输到客户端的所有信息、上下文和异常详细信息。因此，最好至少有一种异常并将其添加到每个服务调用中，oneway 方法除外。

为什么不在oneway 方法上？

好吧，严格来说，你也可以添加它，Thrift 编译器会忽略它（较新的版本会发出警告）。事实上，由于oneway 方法永远不会返回任何值，甚至不会返回异常，所以throws 子句对于oneway 完全没用。

异常处理是不是开销太大了？

另一种选择是忍受上面解释的不受欢迎的行为。但这不是 Thrift 的设计方式，从长远来看，它会产生更多的痛苦而不是收获。

对于似乎很常见的情况，这似乎是相当多的迂回。

不是真的。关于编码，您需要做最少的额外工作，这是真的。但你也应该看看你的努力得到了什么。

一般来说，在任何 API 外观（不限于 Thrift）上都有一个异常处理程序无论如何都是一件好事。这些异常处理程序充当最后的堡垒，通常用于其他目的，例如日志记录、清理与安全相关的内部等等。关于性能：异常是昂贵的，当它们被提出时。异常处理程序的纯粹存在对性能的影响非常有限。

我可以重复使用 TApplicationException，还是从它派生？

我注意到在内部使用了一个 TApplicationException ，它似乎可以很好地工作，但我似乎无法在我的 thrift 文件中使用它，所以它不起作用。

TApplicationException 仅供内部使用，TTransportException 和 TProtocolException 也是如此。你也不应该从他们那里得到。只需在 IDL 文件中声明您的异常，然后让 Thrift 编译器处理其余部分。