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

Question

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

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

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

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

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

Answer 1

HTTP 500

With REST services, an uncaught exception will be translated by web frameworks into an HTTP 500 response code.

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

惯用的异常处理

What is the idiomatic way thrift users handle uncaught exceptions on the server side?

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

未捕获的异常被转化为一般的 TApplication 异常，但它们也可能会捕获意外关闭的传输等效果，正如您已经观察到的那样。显然，不利的一面是，您丢失了可能想要传输给客户端的所有信息、上下文和异常详细信息。因此，最好至少有一种异常并将其添加到每个服务调用中，oneway 方法除外。

为什么不在 oneway 方法中？

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

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

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

it seems to be a fair amount of runaround for what seems like a pretty common case.

不是真的。关于编码，您需要做的额外工作很少，这是事实。但您也应该看看您为此付出的努力得到了什么。

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

我可以重新使用 TApplicationException 或从中派生吗？

I notice there is a TApplicationException used internally which seems like it would work really well, except I can't seem to use it in my thrift files, so that won't work.

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