Ondrej:

Options/opinions on how to handle this correctly:

    A: Logging and continuing

logger.error("Waiting for a warm up singleBenchmarkRunner was interrupted.", e);
continue;

    B: Throwing the InterruptedException to a higher level
        Widely recommended, but does it make sense in our case?
        What is it that we want to tell the caller?

    C: Setting the interrupted status and returning from the method
        Widely recommended, but does it make sense in our case?
        Do we actually tell the caller anything? What does returning too soon mean to it?

logger.error("Waiting for a warm up singleBenchmarkRunner was interrupted.", e);
Thread.currentThread().interrupt();
return;

    D: Throwing a RuntimeException and failing (too?) fast

throw new RuntimeException("Waiting for a warm up singleBenchmarkRunner was interrupted.", e);

    E: Actively waiting (doesn't throw an InterruptedException)
        Uses the CPU extensively for an uninteresting and not needed task

while (future == null) {
    future = warmUpExecutorCompletionService.poll();
}



ge0ffrey:
A will - in most cases - effectively eat the exception (= sometimes goes wrong, but the developer/user doesn't see the notification). Eating the exception is about the worse thing than can happen, because it doesn't force the developer/user to fix the problem, it silently creates explainable problems which reduce long term thrust in our software. The benchmarker does uses the logger.error() itself once too, but that's only to delay the fail fast, instead of eating it: it still ends up throwing an exception instead of returning to the user. -1 on A (even with a delayed throw actually)

B is impossible/undesirable because InterruptedException is a checked exception and we don't want to make our benchmark users jumpt through some hoops of try-catch loops that they don't know what to do in the catch anyway. Big -1 on B

C in that form eats the exception, see reasoning of A. There might be a variation of this that is acceptable.

D should be a subclass of RuntimeException, such as IllegalStateException or IllegalArgumentException. I'd recommend IllegalStateException. +1 on D with an IllegalStateException and the InterruptedException on the cause

E will cause an infinite loop. Big -1 on E