In the years I have spent programming and developing systems, there are only two situations where I found the pattern in question useful (in both cases the supression contained also logging of the thrown exception, I do not consider plain catch and
null return as a good practice).
The two situations are the following:
1. When the exception was not considered an exceptional state
This is when you do an operation on some data, which may throw, you know it may throw but you still want your application to keep running, because you do not need the processed data. If you receive them, it's good, if you do not, it is also good.
Some optional attributes of a class may come in mind.
2. When you're providing a new (better, faster?) implementation of a library using an interface already used in an application
Imagine you have an application using some sort of an old library, which did not throw exceptions but returned
null on error. So you created an adapter for this library, pretty much copying the original API of the library, and are using this new (still non-throwing) interface in your application and handling the
null checks yourself.
A new version of the library comes, or perhaps a completely different library offering the same functionality, which, instead of returning
nulls, throws exceptions and you want to use it.
You do not want to leak the exceptions to your main application, so you supress and log them in the adapter you create to wrap this new dependency.
The first case is not an issue, it is the desired behaviour of the code. In the second situation, however, if everywhere the
null return value of the library adapter really means an error, refactoring the API to throw an exception and catching it instead of checking for
null may be (and code-wise usually is) a good idea.
I personally use exception supression only for the first case. I have only used it for the second case, when we did not have the budget to make the rest of the application work with the exceptions instead of