ClassCastException said:
JCIP does not consider these to be acceptable?
"- Exit the thread by returning from its run() method"
"- Exit the thread by throwing another, unhandled exception, perhaps with
the InterruptedException as its cause"
That seems odd, since the first one is necessary if a thread is to
actually interrupt while not producing any stack trace barf on the
console (for cases when the interruption is NOT a bug) and the second is
necessary if you want good layer decoupling and requiring every
intermediate caller to handle or explicitly pass InterruptedException is
poor layer decoupling. Then the standard method of "transforming" or
wrapping layer-specific exceptions at layer borders seems indicated. In
particular, in the case that the InterruptedException should not happen
in production, you want to log it and either recover or abort, either the
interrupted thread or the whole process/servlet/whatever.
Thank you for considering the intent of the OP in your response.
It is my intent that this worker thread not throw any exceptions and
that all exceptions are considered catastrophic. The worker thread is
writing a write ahead log, so any error is met by shutting down the
thread to preserve the log, notifying waiting threads that it has
shutdown. Waiting threads are waiting within the write ahead log
library, which will detect the shutdown and throw an exception that says
that the write ahead log has gone away. Future calls to the write ahead
log throw exceptions. The absence of the log is unrecoverable.
The obvious way for a write ahead log to fail is for the disk to fill.
Thus, one of the messages you can send to the worker is to switch log
directories, so that long before the disk fills, you can tell the log to
write to a new disk. Why run the train to the end of the line, then put
it back on the tracks after you laid some more? Is that anyway to run a
railroad?
Thus, I have a universal strategy for faults, which is, if things are
not going as you expect, *stop* *writing* to the write ahead log, close
it, shutdown completely, and start the forensics to figure out what went
wrong. The rest of the system will come crashing down, but full disks,
and the like, will do that.
Which is why, sending it an interrupt is something that I would want to
know immediately, so that I'd be in a better position to determine which
bit of code is interrupting threads arbitrarily and excise it.
This discussion helped me see that continue after interrupt is
absolutely not what I want.
So, whether or not I reset the interrupted status on the way down the
drain is probably not that important, but I have no problem with adding
that one line of code.