This can catch you by surprise - pun intended, and could involve some time in debugging, specially as this could happen after code is deployed on a new machine which has a missing jar, for example.
Here is an example of the issue:
class Work implements Callable<Pair<String,byte[]>> {
private String domain;
public Work(String dom) {
this.domain = dom;
}
public Pair<String, byte[]> call() {
try {
return new Pair<String, byte[]>(domain, InetAddress.getByName(domain).getAddress());
} catch (UnknownHostException e) {
return null;
} catch (Exception e) {
System.err.println("unexpected DNS error for: " + domain + " "+e.getMessage());
return null;
}
}
}
//caller code
ExecutorService pool = Executors.newFixedThreadPool(16);
Future<Pair<String,byte[]>> future = pool.submit(new Work("http://lynx.com"));
//sometime later, retrieve the future...
if (future.isDone()) {
try {
Pair<String,byte[]> pair = future.get();
if (pair != null) {
//work with the results
}
} catch (ExecutionException e) {
System.err.println("thread pool error " + e.getMessage());
} catch (InterruptedException e) {
System.err.println("thread pool interrupted " + e.getMessage());
}
}
Here, the scenario is that the Pair class is missing. This class is invoked in the Callable method that returns the result from the thread to the caller. When the caller issues the future.get() call, the concurrency library calls the Callable.call() method, which then causes the JVM to throw the NoClassDefFoundError. The concurrency library dutifully catches this and re-throws the ExecutionException.
It pays to catch the ExecutionException and trace it in your code, even if you would never run the application in resource-tight scenarios when you really have to worry about catching these.
If the ExecutionException was not handled, this application would not fail visibly, but will likely not do what was intended.
