Take the 2-minute tour ×

What is the best practice way of getting Exception Transparency in Java when using an anonymous inner class to run some code.

A frequent pattern that I have seen in real code is using some pseudo Runnable type interface to specify some context for some given code. The best example I can think of in the JDK is the java.security.PrivilegedExceptionAction.

try {
    boolean success = AccessController.doPrivileged(
        new PrivilegedExceptionAction<Boolean>() {
            public Boolean run() throws Exception {
                // do something
                // read file
                FileInputStream fileInputStream = 
                    new FileInputStream(new File("someFile"));
                return true;
} catch (PrivilegedActionException e) {
    if (e.getCause() instanceof FileNotFoundException) {
        // handle IO exception
    } else {
        // impossible no other checked exception

Even though reading the code you can clearly see the inner code only throws a File not found, but we lost the benefits of checked exceptions as the caller is unaware of what exception is actually thrown. A Common bug would be to introduce code into the anonymous inner class that would thrown a new exception and the code would not force you to handle that exception.

What I want is something like what's below, is this type of behaviour achievable without a language change?

public interface PrivilegedExceptionAction<T,V... extends Throwable>
    public T run() throws V;
share|improve this question
I think anonymous inner classes are, in general, a bad idea, mainly because they can't be reused or extended. But this is another reason. I'm interested in any answer too. –  user949300 Nov 12 '11 at 1:06
I have seen Brian's proposal under project lambda, unfortunately this is not available in java 6 –  bluphoenix Jan 21 '12 at 15:18
sun.com links are dead now. The article mentioned is now here blogs.oracle.com/briangoetz/entry/… –  GeneSys May 28 '13 at 9:21
add comment

1 Answer

up vote 3 down vote accepted

I don't see why not. The following code worked.

interface RunIt < E extends Exception >
    void run ( ) throws E ;

class App
    public static void main ( String [ ] args )
        RunIt < RuntimeException > r = new RunIt < RuntimeException > ( )
            public void run ( )
                throw new RuntimeException ( ) ;
        } ;
        r . run ( ) ;
share|improve this answer
What would you do if you need to throw more than one exception? Would you have a RunIt2<E1 extends Exception,E2 extends Exception>. I guess that is not all that bad. I would have to choose which Interface to use depending on what checked exceptions I'm expecting to throw. –  bluphoenix Nov 12 '11 at 4:47
If you need to throw more than one exception, there are 2 options. (1) as you say E1 extends Exception, E2 extends Exception. (2) You could choose E to be a super class of all the exceptions that could be thrown. If you choose 1, then the interface might look like RunIt<E1 extends Exception, E2 extends Exception, ... , E100 extends Exception > to allow for a lot of kinds of checked exceptions. (If there are more than you need, you can set the excess to RuntimeException.) If you choose 2 that kind of defeats the purpose of the exercise. It is not a great solution, but it works. –  emory Nov 15 '11 at 1:08
add comment

Your Answer


