哪些层应该记录异常？

Question

我有一个包含四层的大型单体应用程序，用于满足特定的功能需求。

UI Layer-> Presentation Logic Layer-> Business Logic Layer->Persistent Layer

呼叫流程的一个最小工作示例可以是，

class ProductViewController {
    func showProduct(list){
        // populate list in view
    }
}

class ProductPresenter {
    func sanitiseProduct(list){
        // apply presentation logic to list
        viewController.showProduct(list)
    }
}

class ProductService {
    func filerProducts(list){
        // apply filtering logic to list
        productPresenter.sanitiseProduct(list)
    }
}


class ProductDatabase {
    func retrieveProducts(){
        // retrieve raw product list
        productService.filerProducts(getAllProduct())
    }
}

现在，如果流的任何层中发生任何异常（即query exception in Database layer），我已决定使用适当的TAG和信息将其记录在每一层中，然后返回上层进行传播，以便在调试时，每一层都可以使用适当的过滤器过滤自己的日志标记而不查看其他层（即especially when different teams are responsible for different layers）。

在审查时，我的一位同事评论说，在我的设计中，单个异常/错误将有重复的日志，这可能会降低性能和内存。他的建议是针对特定异常（即query exception in Persistent Layer only）在其中一层应用日志记录。但是，他建议继续向上层抛出异常。

为了性能和内存，我的日志记录方法提供更好的可维护性是否应该改变？处理这种情况的一般建议是什么？

Answer 1

答案很可能是令人恐惧的……这取决于情况。我的意思是，如果您遇到性能或内存问题，那么每一点肯定都会有所帮助。重复的日志条目也可能会带来其他问题（就像每个团队都会查看日志条目/错误，即使它与他们无关）。花时间查看不相关的日志条目可能会浪费团队的好时间，即使他们可以很快就能看到标签）。如果这是一个问题，仅在源头记录它可能是一件好事。

也就是说，可维护性等也是积极的，对于最有可能长期存在的大型整体应用程序，应该特别考虑这些积极因素。我曾多次陷入让事情变得过于复杂的陷阱，希望构建完美的解决方案，但增加的复杂性使得维护变得非常困难，以至于产生了相反的效果，变得非常糟糕。

所以我的建议是，如果当前不存在内存、性能等问题，那么长期存在的单体应用程序的可维护性会获胜。但我想这个答案可能因开发人员而异。