Sometimes because of the hurry in developing a game or because of closing an iteration, some developers find that they couldn’t fix some bugs and they decide to cover that bugs managing some unexpected exceptions or errors.
This practice that must be a serious practice to the eyes of experienced developers, is extended to some developers comunities.
It is true that sometimes avoiding some errors from an external technology, like Java Swing or a KVM implementation from a Mobile Phone Manufacturer, need of managing strange exceptions to solve that problem. Sometimes there is no other way than catching that exceptions for doing nothing and depends on the platform we are using. But when we are managing our logic and our source code, catching generic exceptions in all methods in a non controlled way, can be a practical joke or a nightmare:

/**
 * Controls "key pressed" events
 * @param key Key that has been pressed
 */
public void processKeyPressed(int key) {
    try {
        // Here all logic
        // …
    } catch (Exception ex) {
        // Nothing to do
    }
}

A nightmare because the time of processing that try/catch blocks is high and involves that key detection, AI processing, states changes, movement control, resources loading, painting some elements, the creating and building of characters, the managing of events and actions, and in general everything that must be executed each game cycle, will execute the game too slow.
Not much power in mobile phones could be, but usually we must keep an eye on bad practices that sometimes we did and that developers teams must not make.
If you detect in your developing teams this practice, usually used by low experience developers or the ones that doesn’t look after their work results, you must put a stop to it or you will find a last minute problem. My recommendation is making source code reviews often, making it by developers that don’t know the code they are going to analyse for detecting those bad practises. Some developers will see in this source code reviews something personal, but we must show them that is only a professional activity and that some practises make more complex a product developing.