Behavior of ThreadFactoryBuilder is unclear if backing factory returns null

[cpovirk]

As #3566 points out, ThreadFactoryBuilder.newThread is permitted to return null (and classes like ThreadPoolExecutor are resilient to this).

Our ThreadFactoryBuilder calls newThread and returns it directly or, if the user has requested particular settings on the thread (like a name or priority), it first calls methods like setName on it.

There are a few directions we could go:

• Make ThreadFactoryBuilder no longer permit backing factories that return null: Make its newThread method call verifyNotNull on the backing factory's returned thread, and document the new input requirement and output guarantee.
• Make ThreadFactoryBuilder resilient to backing factories that return null: Skip calls like setName if the backing factory returns null, and document that our newThread method can return null. (This is a behavior change, but it's probably a good one: Our newThread method can already sometimes return null, so this change just makes it do that more often, rather than throw NullPointerException.)
• Document the currently somewhat strange behavior: We permit a backing factory to return null as long as no settings are requested on it -- in other words, then there was probably no reason to use ThreadFactoryBuilder in the first place :)

[v-aksenov]

I think, that method called "newTread" should return new thread. It seems logicaly. And if method cannot create new Thread and return it, then input parameters are wrong. So in this case I agree with your first way - add verifyNotNull verification before creating thread process. If you do not mind, I would like to take this task.

[cpovirk]

If only Java had written the contract that way, this would be a much easier decision :( Given that newThread is documented to be able to return null, the decision is much trickier. My guess is that we'll never get around to investigating which way to go on this. Thanks for the offer, though.