Exception Handling

[Sona Makheeja]

In an interview i was asked

"What are the disadvantages of Exception handling"
i cudnt thnk of anything

I answered: If in the catch block you arent coding to undo the things done the process remains incomplete For eg if two tables are to be updated , first gets updated properly, but b4 second does there is an exception , so the db contains invalid state

but he wasnt Ok with my answer... he said what if the coding is taken care properly???

Can someone help me with the answer.

[Paul Sturrock]

Checked exceptions can be irritating. Think of what OO tries to achieve - creating Objects which contains functionalitly/properties for which they are responsible and nothing else. Suppose you write a piece of code which calls a calculation method in another class. The calculation itself never throws an exception - lets say all it does is adds two integers, but the method is in an EJB. Now your code has to catch an EJBException, a RemoteException, a NamingException etc. What do they have to do with your calculate method? Code that could just be one line is now about ten (much harder to read, more space for errors) and you are requiring your client programmer to know about all these other exception types (why should a JSP writer need to know about a SQLException for example?). This is where you end up with an execption in a layer of code where it is meaningless, and quite often this results is the bad practice of silently ignoring exceptions, or the lazy practice of just catching the generic Exception.

[Stan James]

Here are some arguments. I won't say I buy into all of them ...

* throwing an exception is a giant GOTO which has been a bad practice since, um, the 1960s.

* throwing and catching an exception can be inefficient compared to other techniques.

* adding catch clauses for checked exceptions is a pain (as noted above).

* it's easy to misuse exceptions to indicate problems that aren't that exceptional.

Any of those sound good?

[Patrick Haley]

The Trouble With Checked Exceptions:

1. Breaks encapsulation

2. Imposes On Client: Say you write a package full of classes that I am using in a piece of software, and your classes have checked exceptions in them. Me being the guru developer that I am ( ), I write very clean code, that will never generate those exceptions, but the compiler will still insist that I check them in a try {} catch {} sequence. The unecessary requirement wastes resources.

3. Versioning: say in that same package of classes you developed, you update the code, and in so doing, you need to throw an additional exception. My client software is going to break because it doesn't check for that new fangled exception. There is no contract for this in Java.

4. Scalability: in the small, trivial program examples shown in programming books, exception handling looks like a nice little way of handling errors, but when you try to scale it up to an n-tier system with dozens of objects throwing exceptions at my client software, it becomes a question of, "How many exceptions am I supposed to be checking now?"

5. Readability: try catch catch catch finally.