Question

I am mulling over the idea of writing a program to check for ‘leaky abstractions’ in Java. The one area that popped into mind right away is with exceptions:

public class X {     // this one is fine, Readers throw IOExceptions so it is      // reasonable for the caller to handle it     public void parse(final Reader r)         throws IOException     {     }      // This one is bad.  Nothing in the API indicate that JDBC      // is being used at all.     public void process()         throws SQLException     {            } } 

Note, I do not want an argument on relative merits of checked/unchecked exceptions. What I am looking for is other examples (doesn’t have to be exception handling) that people have that could also be reasonably caught via examining the source code or class files.

I am aware of checkstyle, findbugs, and PMD, and AFAIK none of them deal with this (and I am not opposed to putting the checks into one of those tools rather than write my own).

Are there any other examples of leaky abstractions that you come to mind that could be statically check for?

EDIT:

The reason why the second one is bad is that the method throws an exception where the client has no way of knowing that JDBC (for example, it could be anything) is being used. So the ‘leaky abstraction’ is that JDBC is being used. If the underlying mechanism changed to soemthing else (say JPA which is a different database abstraction library) then the exceptions would all need to change as well. So the underlying database library is being leaked out.

Answer 1

So.

How to detect if an API leaks implementation details or does not keep the same level of abstraction.

You may probably watch the this talk. It explains how good APIs look like and are designed ( you can deduct from the good practices what are the bad practices )

For instance

Functionality should be easy to explain. If its a hard name it’s generally a bad design.

From that you could discover, if the methods or return parameters give detail instructions they are not along with the level of abstraction.

For instance a high level method

 -initProcess(): SGN_MTL 

May be leaking implemntation details on the return value.

The hard part here is to detect when the level of abstraction changes.

For instance in your method it would be ok to throw SQLExceptions all around if the code it self is the implementation of the JDCB layer.

Other source where you can see more of these topics is this list. http://www.jetbrains.com/idea/documentation/inspections.jsp

See the items under ‘Abstraction’ ie.

• Instance variable of concrete class: Report when the type of an instance variable is declared as a concrete class rather than an interface.

The classic example is:

 private ArrayList list; 

when it will be better

 private List list;