Error hiding

In computer programming, error hiding (or error swallowing) is the practice of catching an error or exception, and then continuing without logging, processing, or reporting the error to other parts of the software. Handling errors in this manner is considered bad practice and an anti pattern in computer programming. In languages with exception handling support, this practice is called exception swallowing. Errors and exceptions have several purposes:
Help software maintainers track down and understand problems that happen when a user is running the software, when combined with a logging system
Provide useful information to the user of the software, when combined with meaningful error messages, error codes or error types shown in a UI, as console messages, or as data returned from an API (depending on the type of software and type of user)
Indicate that normal operation cannot continue, so the software can fall back to alternative ways of performing the required task or abort the operation. When errors are swallowed, these purposes can't be accomplished. Information about the error is lost, which makes it very hard to track down problems. Depending on how the software is implemented, it can cause unintended side effects that cascade into other errors, destabilizing the system. Without information about the root cause of the problem, it's very hard to figure out what is going wrong or how to fix it.

The most common underlying cause of error swallowing is the lack of good logging tools and processes while the developer is building software. When faced with an error that can't be easily handled, if the developer has good logging tools, logging an unexpected error does not cost the developer any time or effort. Logging the error should be straightforward (one method call), quick (with no impact to application performance), safe (does not raise any errors or exceptions), and ensures that all information is saved, by recording the type of error and any relevant data associated with it, the stacktrace of the error (so the developer can identify exactly where the error occurred and what instructions led up to it), and the timestamp of the error.

In languages with checked exceptions, all exceptions raised in a method must be listed in a signature of that method. When prototyping and implementing software, code changes often, which means that the type of exceptions that might be raised in a method also change often. Having to adjust the method signature every time something changes slows down development and can be frustrating, so swallowing exceptions as a temporary measure while doing large code changes is appealing. This temporary exception handling code might end up in the released codebase. Even in languages without checked exceptions, adding temporary exception handlers while undergoing large code changes to speed up prototyping can happen, which can lead to error swallowing.

In situations where software must not crash for any reason, error swallowing is a practice that a programmer can easily fall into. For example, a plugin that is running inside another application is expected to handle all errors and exceptions in such a way as to not crash the application in which it is embedded. Blanket catching of errors and exceptions is a pattern that is easy to fall into when attempting to prevent crashes at all costs, and when you combine that with poor logging tools, error swallowing can happen.

When showing errors to users, it's important to turn cryptic technical errors into messages that explain what happened and what actions the user can take, if any, to fix the problem. While performing this translation of technical errors into meaningful user messages, specific errors are often grouped into more generic errors, and this process can lead to user messages becoming so useless that the user doesn't know what went wrong or how to fix it. As far as the user is concerned, the error got swallowed.