Hi folks, so this came up in my code-review: ```data class UpdateCarrierServerFailure( val statu...

# codereview

[George]

Hi folks, so this came up in my code-review:

data class UpdateCarrierServerFailure(
    val status: HttpStatus = HttpStatus.NOT_FOUND,
    val message: String
) : UpdateCarrierServerResult() {
    init {
        logger().error(this.message)
    }
}

Im trying to explain to the author why it is bad to log like that. Any ideas or any other pov is welcomed !

[George]

This is the answer i came up with:

Why it is bad: We should log based on events rather on data. If there is a case where we need to associate a logger with data construction we can always log it on service layer.

[Joffrey]

I'd say:

1. side effects are usually not expected at object construction time, I'd avoid as much as possible
2. this kind of failure object is literally meant to represent the failure, so the action we do to handle that failure (like logging, throwing exceptions, showing a user error) shouldn't be coupled with the data about the error
3. the logger used here is likely not the right one when constructing such objects from somewhere else, we'll want something that's more related to the location of the failure, not the location of the class that represents it