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

If you want your exception to be handled outside the scope of the current method you don't need to to catch it actually, instead you add 'throws' statement to the method signature.

The try/catch statements that you've seen are only in the code where programmer explicitly decided to handle the exception in place and therefore not to throw it further.

Answer 2

I have to say I slightly resent the tone that implies this sort of lax error-handling behaviour is something fundamental to Java programmers. Sure, Java programmers can be lazy, just like every other programmer, and Java's a popular language, so you'll probably see a lot of code swallowing exceptions.

Also, as has been pointed out elsewhere, there are understandable frustrations with Java's enforced declaration of checked exceptions, although personally I don't have a problem with that.

What I have a problem with, I guess, is that you're breezing through a bunch of articles and code snippets on the web without bothering to consider the context. The truth is, when you're writing a technical article trying to explain how some particular API works, or how to get started with something, then you're very likely to skip over some aspects of the code - the error handling that's not directly related to what you're demonstrating is a likely candidate for disposal, especially if the exception is unlikely to occur in the example scenario.

People who write articles of that nature have to maintain a reasonable signal-to-noise ratio, and rather fairly, I think, that means they have to assume you know some basics about the language you're developing in; how to deal properly with errors, and a bunch of other things. If you come across an article and notice a lack of proper error checking, then that's fine; just make sure that when you incorporate those ideas (but of course, never the exact code itself, right?) into your production code, you'll deal with all those bits and bobs that the author sensibly left out, in a manner that's most suited to what you're developing.

I do have a problem with very high-level introductory articles that breeze over such issues without ever returning to them, but please be aware that there's not some particular "mindset" of Java programmers regarding error handling; I know of plenty of your beloved C# programmers who don't bother dealing with all their problems, either.

Answer 3

This is a classic straw man argument. printStackTrace() is a debugging aid. If you saw it on a blog or in a magazine it was because the writer was more interested in illustrating a point other than exception handling. If you saw it in production code, the developer of that code was ignorant or lazy, nothing more. It shouldn't be held up as an example of common practice in the "java world".

Answer 4

I'm afraid that most of java programmers do not know what to do with Exceptions, and quite always consider it as an annoyance that slows their coding of the "nominal" case. Of course they're totally wrong, but it's difficult to convince them that IT IS important to correctly deal with exceptions. Every time I encounter such a programmer (it happens frequently) I give him two reading entries :

• the famous Thinking In java
• A short and interesting article of Barry Ruzek available here : www.oracle.com/technology/pub/articles/dev2arch/2006/11/effective-exceptions.html

By the way, I strongly agree that it is stupid to catch a typed exception to rethrow it embedded in a RuntimeException :

• if you catch it, HANDLE it.
• otherwise, change your method signature to add possible exceptions that you would / could not handle, so your caller would have a chance to do it on his own.

Answer 5

Its lazy practice - nothing short of it really.

Its usually done when you really don't care about the exception - rather than increasing your finger-work.

Answer 6

Please don't ever, ever, ever wrap a checked exception in an unchecked exception.

If you find yourself dealing with exceptions that you don't think you should then my advice is that you are probably working at the wrong level of abstraction.

I'll elaborate: checked and unchecked exceptions are two very different beasts. Checked exceptions are similar to the old method of returning error codes... yes, they are somewhat more painful to handle than error codes but they have advantages too. Unchecked exceptions are programming errors and critical system failures... exceptional exceptions in other words. When trying to explain what an exception is a lot of people get into a complete mess because they don't acknowledge the difference in these two, very different, cases.