3 ms·
An analog in code that I've seen so often I've given up fighting it is this "pattern" (in Java, but it's universal): try { doSomethingImportant();
by commandlinefan 6y ago
An analog in code that I've seen so often I've given up fighting it is this "pattern" (in Java, but it's universal):
try {
doSomethingImportant();
} catch (Exception e) {
logger.error("oops", e);
// continue on, even though the result is useless at this point
}
... and hope that somebody will pay attention to the logs (hint: they won't). Of course, if you can actually recover from an error (hint: you probably can't), you should catch it and recover from it, and of course, you should definitely log what happened so you can investigate later but FOR THE LOVE OF GOD DON'T JUST KEEP GOING!
Unfortunately, this sort of papering over error conditions is not just accepted, but encouraged - most organizations bizarrely seem to prefer to return wrong answers than admit that an error occurred. Old mechanical adding machines had moving parts that would degrade over time, making the answers less and less accurate as the parts started to wear out. Adding machine manufacturers addressed this by adding a gear that would cause the machine to lock up completely so that the operator knew not to continue using it. While it seems obvious that most users would rather get an error than the wrong answer, most programmers seem to consider doing the opposite the "safe play".
- nicoburns 6y agoOh god. I inherited a codebase like this (except in many places it didn't have the log). It was horribly unreliable, and when a customer reported a bug it was almost impossible to tell what had caused it. The funny thing was they had a pretty extensive e2e test suite. But it was mostly useless because it only tested happy paths. The rule is now that if you touch a file for more than a single-line change, you have to remove any such code.
- 3pt14159 6y agoHonestly if I saw someone repeatedly put that type of logic in a PR even after I talked to them about it I'd either lobby to have them fired or I'd quit. I've been on exactly one project like that (a Go backend for a gaming company) and I wtf'd so hard I renegotiated the contract. It's like a car crumbling apart as it drives leaking oil all over the place. Complete chaos.
- throwaway_pdp09 6y agoA kind of not-assertion then. On a related note, perhaps someone can help me. In C# MS has decided that an assertion means to pop up a stack trace in a modal dialog, then continue. This seems wrong. Any insights as to why they do this?
- mint2 6y agoThis note and error in a log is the default behavior of SAS. It’s and abhorrent language.
- slezakattack 6y agoYes, I've seen this as well and from my observation, it seems to boil down to company culture and a lack of product direction. A company that refuses to accept that errors and faults happen tends to permeate into the code. A lot of people that work on the product side will say "I want us to have no failures" without understanding that things simply WILL fail at times and we need to understand what the user experience should be if this were to happen. This is especially true of external services that you have no control over (i.e. the usage of a push notification system).