I'm not a fan of logging errors and returning success codes in lieu of throwing them. It leads to some very nasty support tickets and difficult to debug problem

I'm not a fan of logging errors and returning success codes in lieu of throwing them. It leads to some very nasty support tickets and difficult to debug problems. There's also a lot of mixed concerns here around in place logging and analytics collection for something that is a very business-logical focussed class. If you're wanting to do things like this, I'd encourage you to have a look into a message driven Domain driven design structure. It's approach would be: - remove all logging and analytics concerns from the class - throw errors based on business rule violations, or alternatively publish a failure type message if it's logic path that had compensating actions - publish all mutations of the shopping cart as immutable events - subscribe to events related to analytics/logic and do that work in a handler, or do it in a higher level application service so the shopping cart just contains shopping cart concerns A lot of this can be distilled down to basic DRY and SRP principals