Why do Java people frequently consume exceptions silently?

Question

I never did any serious Java coding before, but I learned the syntax, libraries, and concepts based on my existing skills (Delphi & C#). One thing I hardly understand i

Answer 1

From experience, Swallowing an exception is harmful mostly when it's not printed. It helps to bring attention if you crash, and I'll do that deliberately at times, but simply printing the exception and continuing allows you to find the problem and fix it, and yet usually doesn't negatively effect others working on the same codebase.

I'm actually into Fail-Fast/Fail-HARD, but at least print it out. If you actually "Eat" an exception (which is to truly do nothing: {}) It will cost someone DAYS to find it.

The problem is that Java forces you to catch a lot of stuff that the developer knows won't be thrown, or doesn't care if they are. The most common is Thread.sleep(). I realize there are holes that might allow threading issues here, but generally you know that you are not interrupting it. Period.

Answer 2

You would usually swallow an exception when you cannot recover from it but it is not critical. One good example is the IOExcetion that can be thrown when closing a database connection. Do you really want to crash if this happens? That's why Jakarta's DBUtils have closeSilently methods.

Now for checked exception that you cannot recover but are critical (usually due to programming errors), don't swallow them. I think exceptions should be logged the nearest as possible to the source of the problem so I would not recommend removing the printStackTrace() call. You will want to turn them into RuntimeException for the sole purpose of not having to declare these exceptions in you business method. Really it doesn't make sense to have high level business methods such as createClientAccount() throws ProgrammingErrorException (read SQLException), there is nothing you can do if you have typos in your sql or accessing bad indexes.

Answer 3

If you have a checked exception and you don't want to handle it in a method, you should just have the method throw the exception. Only catch and handle exceptions if you are going to do something useful with it. Just logging it is not very useful in my book as users rarely have time to be reading logs looking for exceptions or know what to do if an exception is thrown.

While wrapping the exception is an option, I would not suggest you do this unless; you are throwing a different exception to match an exist interface or there really is no way such an exception should be thrown.

BTW: If you want to re throw a checked exception you can do this with

try {
   // do something
} catch (Throwable e) {
   // do something with the exception
   Thread.currentThread().stop(e); // doesn't actually stop the current thread, but throws the exception/error/throwable
}

Note: if you do this, you should make sure the throws declaration for the method is correct as the compiler is unable to do this for you in this situation.

Answer 4

It is only consumed silently if the catch block is empty really.

As far as articles goes they are probably more interesting in proving some other point besides how to deal with exceptions. They just want to get straight to the point and have the shortest possible code.

Obviously you are right though, exceptions should at least be logged if they are going to be 'ignored'.

Answer 5

I find there are often 2 reasons this is done

1. Programmer was lazy
2. Programmer wanted to guard an entry point into there component (correctly or incorrectly)

I do not believe this is a phenomenon limited to Java. I've seen such coding often in C# and VB.Net as well.

On the surface it's quite shocking and looks terrible. But really it's nothing new. It occurs all the time in C++ applications which use error code return values vs. exceptions. The difference though is that ignoring a potentially fatal return value doesn't really look any different than calling a function that returns void.

Foo* pFoo = ...;
pFoo->SomeMethod(); // Void or swallowing errors, who knows?

This code looks better but if SomeMethod() were to say return an HResult, it would be semantically no different than swallowing an exception.

Answer 6

A System.out print or e.printStackTrace() - which implies use of System.out is usually a red flag meaning someone didn't bother to do a diligent job. Excepting desktop Java Applications, most Java apps are better off using logging.

If the failure mode for a method is a no-operation, it's perfectly fine to eat an exception, whether you record the reason (and existence) or not. More typically, however, the catch clause should be taking some sort of exceptional action.

Rethrowing an exception is something that's best done when you either use the catch to clean up part of the work at a level where the necessary information is still available or when you need to transform the exception to an exception type more amenable to the caller.