We should classify exceptions by the _action_ required to fix them, not by the circumstances in which they appeared. "DivideByZeroException" is useless, "User e

We should classify exceptions by the _action_ required to fix them, not by the circumstances in which they appeared. "DivideByZeroException" is useless, "User error: 31st of February is not a date" or "Internal error: count is zero" are a whole lot more actionable. Java's menagerie of exceptions is an anti-pattern. I grant you that there is a third class of exceptions, "remote unavailable", for which the error handling is to retry X times, then promote to "system broken" and let the user retry later. For all intents and purposes, "system broken" is a better name for "code error", covering also cases where the DevOps team should fix the hardware or dependencies on third party systems. [Configs are funnily written code]. Often times the "retry X times" logic is wrapped nicely in one's RPC infrastructure of choice, so what the app developer has to deal with is either "user error" or "system broken".