处理异常，有没有比较好的 practice 或者方法？

[yazoox]

最近在改一些老的 sdk 代码，有的抛出了异常，有的没有。 使用端，有的异常处理了，有的又没有。debug 时候，代码乱跳，一直也找不到合适的地方处理。

所以，特意来请教一下。

大家代码时，通常，是如何处理异常的 （即 throw exception ）

在设计 API，class/methods 的时候，什么时候处理掉异常不抛出，什么时候直接抛出去，交给外面去处理。

有没有比较好的设计规范或者 可以参考的 best practice ？

谢谢

[kop1989]

我的原则是，本层可以解决的异常，就在本层处理，本层解决不了，或者需要额外信息，代价太大的，抛给上层。
然后顺道我想讨论个问题。java 抛异常是强制上层必须 Catch 的，但是 C#好像没有这种机制，这样非常容易忘记异常处理逻辑，C#是出于什么设计目的？

[teketernal]

平常写 Java 的 rest API，都是继承 RuntimeException 自定义业务异常，然后随便抛。
然后统一在 Controller 层写切面或者注入 GlobalExceptionHandle 处理异常，封装 ErrorCode 。

[wongy]

Java 代码我是用 @ControllerAdvice + @ExceptionHandler 处理异常

[wenlele]

归根结底，这都是因为没想清楚业务对象的职责。

以分层的架构看，每一层有自己的职责，每个层有自己的职责，因此也会有自己职责下的私有领域概念，但层与层之间的接口（包括抛上去的异常）应该是共享的概念，下层不能将其私有的概念返回给上层。

在 OOP 里，具体到某一个类或类的方法，也是如此。它的职责或者说接口定义决定了它应该返回什么，在错误情况应该怎么返回结果（通过异常还是返回对象）。有时候，可以抛异常，也可以返回特殊的结果；我觉得没必要强求坚持每一种，只要内部统一风格，保持一致性就可以了。如果担心其他人不遵守，最后引用一些代码规范的自动化检测，确保风格能统一。

然而，在一些古老的代码，尤其是以前的人不重视一致性，你说这种情况很正常。一般也没必要重构，只要确保之后的改动遵循目前多数人认同的风格就行，而不是引入另一种全新的而且没经过多数人审核的风格……