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