我正在尝试使用C＃的Thrift服务。使用REST服务，Web框架将未捕获的异常转换为HTTP 500响应代码。
对于thrift，据我所知，我需要在thrift文件中声明所有可能的异常类型。这给我留下了两个我能想到的选择：
第一个选项可行，但对于看起来很常见的情况来说似乎是一个相当大的周期。我注意到内部使用了一个TApplicationException似乎它可以很好地工作，除了我似乎无法在我的thrift文件中使用它，所以这将无法工作。
thrift用户在服务器端处理未捕获的异常的惯用方法是什么？
答案 0 :(得分：2)
使用REST服务，Web框架将未捕获的异常转换为HTTP 500响应代码。
这是一个委婉的说法，“让服务器在未捕获的异常中惨遭失败”。 REST框架遵循这些策略，因为REST是围绕HTTP动词，响应和行为而有意设计的。所以反过来说：HTTP状态代码不会以某种方式添加到REST实现中，它们是REST的基本原则。
thrift用户在服务器端处理未捕获的异常的惯用方法是什么？
简短回答：你不是那样的。
未捕获的异常会通过一些运气转化为通用的TApplication异常，但它们也可能会捕获像意外关闭的传输一样的效果，正如您已经观察到的那样。显然，缺点是，您丢失了可能要传输到客户端的所有信息，上下文和异常详细信息。因此，除了oneway方法之外，最好至少有一种异常并将其添加到每个服务调用中。
oneway方法？嗯，严格来说，你也可以添加它，Thrift编译器会忽略它（较新的版本会发出警告）。实际上，由于oneway方法没有返回任何值，甚至没有返回异常，throws子句对oneway完全没用。
替代方案是忍受上述不良行为。但这并不是Thrift的设计方式，而且从长远来看会产生更多的痛苦。
对于看起来很常见的案例来说，这似乎是一个相当大的周期。
不是真的。关于编码，你有额外的工作量，这是真的。但是你也应该看看你为这项工作获得了什么。
一般来说，在任何API外观（不限于Thrift）上设置异常处理程序都是件好事。这些异常处理程序充当最后的堡垒，通常用于其他目的，如日志记录，清理安全相关的内部等等。并且就性能而言：当它们被提升时，例外代价很高。异常处理程序的纯粹存在确实只会对性能产生非常有限的影响。
我注意到内部使用的TApplicationException看起来效果非常好，除非我似乎无法在我的thrift文件中使用它，所以这样做无效。
TApplicationException仅供内部使用，TTransportException和TProtocolException也是如此。你也不应该从中衍生出来。只需在IDL文件中声明您的异常，让Thrift编译器负责其余部分。