比如有下面一个console程序, 应该把try catch设计在程序更顶层的A呢,还是更靠近异常发生调用处的B呢?
或者是根据Exception的种类(致命故障或者一般异常)区别对待呢?

==== Program.cs ====
main()
{
    IService service = new Service();
    service.Foo(); // A
}

==== Service.cs ====
class Service:IService
{
    private readonly IAnotherService _anotherService;

    public void Foo()
    {
        var value = _anotherService.Bar();   // B
        // ...
    }
}

==== AnotherService.cs ====
class AnotherService:IAnotherService
{
    public string Bar()
    {
        if (...)
            throw new Exception();
    }
}
  
--
FROM 60.180.25.*

向上抛出是指catch throw，还是直接不处理它让上层抉择呢？
  
【 在 coocodelie ( 懒得输入) 的大作中提到: 】
:  在哪一层能对异常做出处理（如重试、变更执行路径、再封装），就在那层捕捉。否则向上抛出。
:  
:  【 在 ustcBoy 的大作中提到: 】
:  : 比如有下面一个console程序, 应该把try catch设计在程序更顶层的A呢,还是更靠近异常发生调用处的B呢?  
--
FROM 115.221.134.*

嗯，我也是这么想的。之前不太喜欢用异常，现在又感觉异常在一些情况下可以直接越过中间层穿透到更上层的调用，可以简化中间层的转发处理，也是挺好的方法。
  
【 在 coocodelie ( 懒得输入) 的大作中提到: 】
:  简单说就是有能力处理就处理，没能力就不管。如何处理看业务逻辑。
:  注意catch住异常是为了处理，如果不处理就没必要catch。至于处理是写个日志、重试、还是弹窗提示是业务确定的。
:  
:  【 在 ustcBoy 的大作中提到: 】
--
FROM 60.180.25.*