Which layers should be logging for exceptions?

Question

I have one large monolithic application with four layers for specific functional requirements.

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

One minimal working example for call flow can be like,

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

Now if any exception happens in any layer of the flow (i.e. query exception in Database layer) I have decided to log it in each layer with appropriate TAG and info and throw back to upper layers for propagating so that while debugging, each layer can filter its own logs using appropriate TAG without looking into other layers (i.e. especially when different teams are responsible for different layers).

While reviewing, one of my colleagues commented that in my design, there will be duplication of logs for a single exception/error which might cost performance and memory. His suggestion is to apply logging in one of the layers for specific exceptions (i.e. query exception in Persistent Layer only). However, he suggested to continue throwing the exception to upper layers.

Is my logging approach which provides better maintainability should be changed for the sake of performance and memory? What are the general suggestions to deal with this situation?

Answer 1

The answer is most likly the dreaded.. It depends. I mean if you have issues with performance or memory sure every little bit helps. Also having duplicated log entries can give other issues (like every team looking at the log entry/error even if it is not relevant to them. Spending time looking at irrelevant log entries might be a waste of good time for the teams even if they can see the tagging pretty fast). Logging it only at the source might be a good thing if that is an issue.

That said maintanability and such are also positives that should be considered specially with large monolith applications that will live for a long time most likely. I have fallen many times in the trap of making things too complex in hopes of building the perfect solution but the added complexity makes it so hard to maintain that it has the opposite effect of being really bad.

So my suggestion is if there are no current issue with memory, performance or such, maintainability wins for longlived monolithic applications. But I guess this is answer probably differs from developer to developer.