对于你问的问题，实际上是一个异常处理策略的问题。至于以何种语言为例，道理都是一致的。说说我的看法：

• 首先需要对异常分类。当前抛出异常是属于系统异常还是业务异常，如果是系统异常，不要抛出，如果是业务异常，则需要抛出。这里的难点在于分类，得视具体情形而定，例如：同样的一个资源访问IO异常IOException，对于有些一些持久化数据的调用方法更多就是系统异常，因为默认的话，不应该存现这样持久化存储对象不存在；而对于一个打开文件目录的调用方法就更偏向于是提供的文件目录有误，这样应包装成业务异常；
• 其次需要划分异常范围。在一个模块内部的异常，往往不要抛给模块的调用者，因为对于内部的异常，调用者也无法知道如何处理。另外，系统对外暴露的接口，最好通过错误码返回，不要抛出异常，这会导致外部系统理解歧义，因为外部系统无法知道调用异常到底是表示业务请求失败，还是系统出错？反之，对于调用外部系统时捕获的异常，往往上层的应用也不知道如何处理，所以一般的话，也尽量不要抛给上层调用者；
• 此外，在涉及操作系统调用的方法中，对于方法抛出的类似中断异常等系统异常，最好选择抛出给调用者，以防止私吞异常导致屏蔽了商城调用者对于中断异常的特殊处理逻辑。

这个不是看情况吗。如果 Exception 出现的概率比较大，而且是可以预测的（比如文件无法打开，输入不符合要求之类的），当然就就地解决了，这类异常往往不能算真的“异常”，也是系统功能的一部分。如果是不可以预测的其他异常就 raise 好了。

这个取决于你需要在哪一级处理这个异常

1. 如果你可以在最底层就处理掉异常，那就可以直接处理掉
2. 如果上层的代码需要获取这个异常进行不同的处理，那就抛出去