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

You should see this very often if the programmer does his job right. Ignoring Exception is a bad, bad practice! But there are some reasons why some might do this and the more apporiate solutions:

• "This wont happen!" Sure, sometime you "know" that this Exception won't happen, but its still more appropiate to rethrow a runtime exception whith the occoured Exception as "cause" instead of just ignoring it. I bet it will occour sometime in the future. ;-)

• Prototyping Code If you're just typing your stuff down to see if it works out you might want to ignore all Exceptions that might occour. This is the only case i do some lazy catch(Throwable). But if the code will turn out into something useful, i include proper exception handling.

• "I dont know what to do!" I saw much code, especially library code, which swallows occouring exceptions because in this layer of the application no proper handling can be done. DONT DO THIS! Just rethrow the exception (either by adding a throws clause in the method signature or wrapping the exception into a library specific one).

Answer 2

because it is a best practice. I thought everybody knew.
but the cold truth is that nobody really understands how to work with exceptions. The C error handing style made so much more sense.

Answer 3

I have always thought, that's similar to the following scenario:

"A man gets shot.

He holds his breath and has enough strength to take a bus.

10 miles later the man gets off of the bus, walks a couple of blocks and dies."

When the police gets to the body, they don't have a clue of what has just happened. They may have eventually but it is much harder.

Better is:

"A man gets shot and he dies instantly, and the body lies exactly where the murder just happened."

When the police arrives, all the evidence is in place.

If a system is to fail, better is to fail fast

Addressing the question:

1. Ignorance.
   +
2. Sloth

EDIT:

Of course, the catch section is useful.

If something can be done with the exception, that's where it should be done.

Probably that is NOT an exception for the given code, probably it is something that is expected ( and in my analogy is like a bulletproof jacket, and the man was waiting for the shot in first place ).

And yes, the catch could be used to Throw exceptions appropriate to the abstraction

Answer 4

As others have pointed out, the reason you see this is for one of three reasons:

1. An IDE generated the try-catch block
   • The code was copied and pasted
   • The developer put the stacktrace in to debug but never came back to handle the exception properly

The last point is the least likely to occur. I say this because I don't think anyone really debugs this way. Stepping through code with a debugger is a much easier way to debug.

The best description of what should be done in a catch block can be found in Chapter 9 of Effective Java by Joshua Bloch.

Answer 5

You should always forward it on or handle it suitably in a real-world context. A lot of articles and tutorials will simplify their code to get the more important points across though and one of the easiest things to simplify is error-handling (unless what you are doing is writing an article on error-handling that is :)). As java code will check for exception handling then putting a simple silent (or logging statement) catch block on is the simplest method to provide a working example.

If you find this in anything other than example code, feel free to forward the code onto TDWTF, although they may have too many examples of it by now :)

Answer 6

The combination of checked exceptions and interfaces lead to the situation that the code must handle exections that never ever get thrown. (The same applies to normal inheritance, too, but it's more common and easier to explain with interfaces)

Reason: The implementation of an interface may not throw (checked) exceptions other than those defined in the interface specification. For that reason, the creators of an interface, not knowing which methods of a class implementing the interface might actually need to throw an exception, might specifiy that all methods might throw at least one type of exception. Example: JDBC, where everything and its grandma is declared to throw SQLException.

But in reality, many methods of real implementations simply cannot fail, so under no circumstances, they ever throw an exception. Code calling this methods must still somehow "handle" the exception, and the easiest way is to do that swallow the exception. Nobody wants to clutter his code with seemingly useless error-handling that never ever gets executed.