3 ms·
See jcrites comment here https://news.ycombinator.com/item?id=11842726 https://news.ycombinator.com/item?id=11842726 for an example where neither the code nor t
by sgift 10y ago
See jcrites comment here https://news.ycombinator.com/item?id=11842726 https://news.ycombinator.com/item?id=11842726 for an example where neither the code nor the data has a bug. Broken sockets are simply a part of distributed systems the code has to deal with.
(If you feel that "the network should be reliable" is a valid answer, see: https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...)
- pacala 10y agoWe 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".