4 ms·

There are two kinds of exceptions. A bug in the data or a bug on the code. The only action to take is to pass detailed info to the user and/or the coder. Fix th

by pacala 10y ago

There are two kinds of exceptions. A bug in the data or a bug on the code. The only action to take is to pass detailed info to the user and/or the coder. Fix the bug and try again beats any precanned exception recovery code one might waste time implementing.

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 ago
  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".
barrkel 10y ago
That's not right. Exceptions usually aren't bugs. See my comment here: https://news.ycombinator.com/item?id=11843464 https://news.ycombinator.com/item?id=11843464
cbsmith 10y ago
Those aren't exceptions, those are bugs. Exceptions happen all the time because of operational errors.

by pacala 10y ago

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 ago
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".

barrkel 10y ago

That's not right. Exceptions usually aren't bugs. See my comment here: https://news.ycombinator.com/item?id=11843464 https://news.ycombinator.com/item?id=11843464

cbsmith 10y ago

Those aren't exceptions, those are bugs. Exceptions happen all the time because of operational errors.