Violent Agreement with "You should let it crash"

I nod my head in violent agreement with Erik Kronberg's You should let it crash.

Gheesh.  Frequently, I feel like I am in the minority with this opinion.

Take, for example, this third-party vendor Java code that I was perusing once:

    try {
        ....
        for(int i=0; i < someVector.size(); i++) {
            obj = someVector.get(i);
            obj.doSomething();
        }
    }
    catch(Exception e){ }

This is (pretty close to...) REAL CODE from a REAL PRODUCT that I worked with once.

Do you want to know what the problem with this code was?

Here's the problem:  See that "catch(Exception e) {}" block?  Well, it turns out that this block was semi-frequently catching an java.lang.ArrayIndexOutOfBoundsException.

I'm going to let you think about this for a moment....

The problem with the code in the product that I was working with was that this "catch" block was obscuring a very real problem in the code.

When I look at code like this, here is how I interpret the original programmer's intentions as he/she wrote the code:

There seems to be a problem here in this code.  However, I'm too lazy to actually figure out what is going wrong here.  Instead of fixing the actual problem that is wrong here, I am going to sweep the problem under the rug.  This might cause some cascade of strange problems in the future execution of this program, and fixing these new problems might take 100 times longer to fix because of this shoddy coding practice that I am employing here, but I am OK with this.

I am a big believer in "always keep your program's execution in a known state".  If the program's execution is not in a known state, then it would be best if this problem were fixed sooner rather than later.  Fixing the problem "sooner" might involve letting your program crash, logging the error, and then restarting.  But, sweeping problems under the rug is simply not acceptable.