Good thoughts. Here are some more thoughts: The "Can't x because of y" pattern is a nice one. But it can be difficult to apply in practice. We write functions

Good thoughts. Here are some more thoughts: The "Can't x because of y" pattern is a nice one. But it can be difficult to apply in practice. We write functions at particular levels of abstraction; indeed it is good advice to avoid writing functions that do work at multiple levels. However, the "x" and "y" in the pattern often exist at multiple levels. "x" should be something related as closely as possible to user intent. The user wants something done. It can't be done. The error message explains why. The "y" is more low level; it is close to the direct cause of the failure. Unfortunately, due to our wonderfully designed architecture, with its separation of concerns, etc., the knowledge of what "x" is and the knowledge of what "y" is reside in different places. So the function that runs into the problem with "y" does not actually know that the task to be performed is "x". Getting those two pieces of knowledge together in the same place takes work. That's work most of us don't want to do. It may even be work that we rationally decide not to do, based on a cost-benefit analysis. After all, what user ever said, "I love this app; it has great error messages." Nonetheless, the ideas in this article are helpful ones, I think.