作为Thrift-RPC的server方, 是否应该抛异常给clien端?

Question

实际现象

1. 作为server端, 代码总是有可能陷入某种异常情况, 这个时候需要把此时的错误信息告诉client

2. Thrift 中, server可以抛异常给client, 但是在实际运用中, 我发现抛异常给client, 并不是很好的体验

3. 又查了些资料, 说「通常建议返回错误码给client ( 实际上是一个 Union(是否成功, 错误码, 错误detail) )」

以上,

• 如果抛异常, client需要去catch异常, 但是异常貌似不能携带更多信息过来

• 如果是错误码, client需要去check返回值, Union好像更加灵活

预期现象

1. 最佳实践是如何的?

上下文环境

• 虽然讨论的是thrift, 但是范围应该是 RPC

• 操作系统: Linux

Answer 1

不管是范畴是thrift还是RPC，都应该尽力保证不会抛出异常，catch掉所有可能的异常，并且考虑catch到的异常是否有必要告知客户端，更别提主动去抛异常这种想法了。

我们做server的，一定要可控和无二义性，这是很重要的。

更好的方案当然是返回状态码和状态信息了，而且不仅是发生错误的时候要返回错误码，成功的时候，也要明确的告知客户端，他的请求成功了。

Answer 2

1、返回自定义状态码

2、尽量不要抛异常，防止有恶意客户端，api中抛异常，不明确的异常则记录日志