A question probing your expectations -- I can't decide, really. So, imagine any of these scenarios:
1) a test case or a suite times out and leaves background threads running, 2) a test completes and leaves background threads running, The framework will try to Thread.interrupt() all leaked threads. I expect this may result in exceptions being propagated up the stack, possibly up to uncaught exception handler level. Normally uncaught exceptions would be reported to the console and queued to be included as a test failure but since we've timed out (or we know it's a thread leak) these exceptions don't seem to be of any real value, right? So, the question is: should any uncaught exceptions be reported at all times (possibly obscuring the original cause of the problem) or should they be suppressed after a timeout/ known thread leak occurred? I've been thinking a about it for a while and I think they should be suppressed. I don't see any real value in knowing something failed after an external call to interrupt(). As a side note -- in the next release when background leaked threads cannot be cleaned up (interrupted), any remaining tests will be ignored. There is simply no reliable way to properly "clean up" the environment then and assure no background noise (other than restarting the JVM). Dawid --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
