That is not my argument or thinking. I may, for example, want one component, but it has two types (or more) or error reporting that I want. I am now forced to d

That is not my argument or thinking. I may, for example, want one component, but it has two types (or more) or error reporting that I want. I am now forced to decouple that into two components. But, it shouldn't be two components, otherwise I would have already made it two components. Furthermore, anything that should be 2 or more components is rather unlikely to also require exactly the same kind of split for error handling. I anticipate the result being a bunch of artificially split up components, each which knows way too much about other components (because they should have been one component). It just sounds like a mess. Not the worst mess in the world, to be sure, but error handling just isn't the way that I want to be forced to architect my system. Imagine, for example, I declared that primitive types are important, and thus you have to create components that either work with int, or double (or char vs unicode, or whatever). For some project you might just split things up like that anyway, but it would be pretty unusual in most cases. Or, if that seems contrived, I say const correctness is important, and thus components must be const or not. Elaborate with any language feature you consider important... tl;dr: Yes, think long and hard about error handling. But no, I don't necessarily want/need/like organizing code into components based on that need. Error handling is only one of many competing pressures on how I might organize code.