我正在试验使用C#的Thrift服务。使用REST服务，web框架将未捕获的异常转换为HTTP500响应代码。
对于节俭，据我所知，我需要在节俭文件中声明所有可能的异常类型。这给我留下了两个我能想到的选择：
- 声明InternalServerError类型并将其添加到每个方法中。每个处理程序方法都需要捕获未处理的异常并重新抛出我的特殊类型
- 在这种情况下，让客户端体验默认行为，即套接字意外关闭
第一个选项会起作用，但对于一个非常常见的情况来说，这似乎是一个相当多的绕过。我注意到内部使用了一个TApplicationException，看起来它会很好地工作，只是我似乎不能在旧文件中使用它，所以这不起作用。
节俭用户在服务器端处理未捕获异常的惯用方式是什么？
HTTP 500
使用REST服务，未捕获的异常将由web框架转换为HTTP500响应代码。
这是">让服务器调用在未捕获的异常上惨败"的委婉说法。REST框架遵循这些策略，因为REST是围绕HTTP谓词、响应和行为精心设计的。因此，情况正好相反：HTTP状态代码不会以某种方式添加到REST实现中，它们是REST的基本原理
特殊异常处理
节俭用户在服务器端处理未捕获异常的惯用方式是什么？
简短的回答：你不想那样。
幸运的是，未捕获的异常会被转换为通用的TApplication异常，但正如您已经观察到的那样，它们也可能会捕获意外关闭的传输等效果。显然，不利的一面是，您丢失了可能要传输到客户端的所有信息、上下文和异常详细信息。因此，最好至少有一种异常，并将其添加到除oneway方法之外的每个服务调用中。
为什么不采用oneway方法呢
严格来说，你也可以添加它，Thrift编译器会忽略它(新版本会发出警告)。事实上，由于oneway方法永远不会返回任何值，甚至不会返回异常，因此throws子句对于oneway来说是完全无用的。
异常处理程序的开销不是太大了吗
另一种选择是忍受上面解释的不想要的行为。但Thrift并不是这样设计的，从长远来看，它会带来更多的痛苦而不是收益。
对于一个看似很常见的情况来说，这似乎是一个相当多的跑路。
不是。关于编码，您只需要最少的额外工作，这是真的。但你也应该看看你的努力会得到什么。
一般来说，在任何API门面(不限于Thrift)都有一个异常处理程序是一件好事。这些异常处理程序充当最后的堡垒，通常用于其他目的，如日志记录、清理与安全相关的内部事务等。就性能而言：异常在提出时代价高昂。纯粹存在的异常处理程序对性能的影响非常有限。
我可以重复使用TApplicationException，还是从中派生
我注意到内部使用了一个TApplicationException，它似乎运行得很好，只是我似乎无法在旧文件中使用它，所以它不起作用。
TApplicationException仅供内部使用，TTransportException和TProtocolException也是如此。你也不应该从它们派生。只需在IDL文件中声明您的异常，然后让Thrift编译器来处理其余部分