The kludge is the fact that `Queue.pop(true)` raises `ThreadError` and not something like `EmptyQueueException`. I'd rather not catch `ThreadError` on the whole block, for the same reason you mention : it is going to *silently* catch too mutch.

Looking at the source code of `Queue` shows that most of the action takes place in `Mutex.synchronize` with some opportunities for `ThreadError`s (in `Mutex.lock` for instance). Even catching ThreadError for the single `pop` call may lead to a case of catching too much.

In any case I prefer this little kludge to the previous unsynchronized check-then-act idiom that was bound to break (leaving a thread indefinitely waiting). And the downside of this kludge is that in case of a runtime error during the `pop` call, the upload of files will silently kill a thread, which may lead the process to stop before completion (which we can easily detect), or not. That's not really a problem IMHO.

FYI, if you grep the Redmine source code, you'll find 15 instances of `rescue nil`, and I found hundreds in the set of gems required to run it.