logging - 哪些层应该记录异常？

Question

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

UI层 -> 表示逻辑层 -> 业务逻辑层 -> 持久层

调用流程的一个最小工作示例可以是这样的，

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())
    }
}

现在，如果流程的任何层发生任何异常(即数据库层中的查询异常)，我决定使用适当的TAG和<在每个层中记录它并返回到上层进行传播，以便在调试时，每个层可以使用适当的标签过滤自己的日志，而无需查看其他层(即特别是当不同的团队负责不同的层时)。

在审查时，我的一位同事评论说，在我的设计中，单个异常/错误的日志会重复，这可能会降低性能和内存。他的建议是在某一层中针对特定异常应用日志记录(即仅在持久层中查询异常)。但他建议继续向上层抛出异常。

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

Answer 1

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

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

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