I was working on some java code and as usual oracle was throwing a cryptic error saying "table not found" but not specifying the table name. Its not my code and the code is in a complete mess - I wanted a quick fix, so in the method that is calling preparedStatement.execute() I wrapped it with

try {

preparedStatement.execute()

}

catch(SQLException e){

throw new Exception( "Could not execute |" + sql + "|", e);

}

Two points:

point 1) why cant the oracle driver do this for us and give clear error messages - 4 years ago I tried to fix this problem by decompiling the classes12.jar file - but I think the jad decompiler was not working and I could not get the code to recompile.

point 2) I know that java was designed with the feature of showing the types of exceptions thrown in the method signature. Over the 4+ years I worked with java - I found this feature to be completely pointless.

reason a) When an exception is thrown 95% of the time - the code simply prints the exception to the log and maps it to an error message for the user - knowledge of the specific exceptions has little value. If you want to do something special for a particular type of exception - you will discover this Exception type during testing and can add a specific catch for it.

reason b) It creates tighter coupling between the caller and the method - since the caller is encouraged to know about the specific exception (in this case: SQLException). The caller just wanted to read the data - he didnt need to know that a SQL database was being used. If a different persistent store (such as file) was swapped in the caller code needs to changed - With the refactoring tools available this is not really a problem - my point is it is creating tighter coupling. Creating a hierarchy of Exception types (eg. PersistanceException) has always looks beautiful on a class diagram - but seems to encourage overdesign with multiple layers of abstraction before the need for this abstraction exists.

reason c) All methods can thow runtime exceptions (eg NullException ) - so the method signature is just a subset of all of the exceptions that can be thrown. You still have to expect and handle exceptions that are not listed.

Personally I think we should avoid this "feature" of java and standardize on throws Exception in method signatures throughout the code :)