ThreadPool.QueueUserWorkItem returns false on failure!

ThreadPool.QueueUserWorkItem is commonly used to execute some task in the background at a later point in time using a thread from the thread pool. If you read the MSDN documentation carefully, you’ll note it says:

Return Value

true if the method is successfully queued; otherwise, false.

Exception type Condition


An out-of-memory condition was encountered.

Wow! It might just return false if it fails instead of throwing an exception. This must be one of those early APIs that they didn’t get right the first time and couldn’t change later for legacy reasons. It also uses ApplicationException, which seems very odd. I rarely see code that checks the result, including the sample code on the MSDN documentation site! This could cause unexpected failures in your application.

Comments (6)

  1. AC says:

    You should probably have a talk with Brad Abrams.

    Exceptions and errors are different.  Exception is not a mechanism to throw errors.  A function can throw an exception if it thinks continuing from that state would fail the program.

    If QueueWorkItem fails, he should just return an error.  If QueueWorkItem ends up in a state that the program can no longer continue, then by all means throw an exception.

    Then what is the purpose of the exception handling? It should just save some state, give a meaningful error message and exit.

    Regarding your comment on not checking return code, I am sorry to say, a person writing such code should move to marketing department.

    Summary:  Exceptions are irrecoverable errors, that’s it.

  2. dancre says:

    Exceptions *are* an error handling mechanism. FailFast is the mechanism for irrecoverable errors. If you can’t continue excecution, you should FailFast, not throw an exception.

    A function should throw an exception if it doesn’t do what it says it’s going to do. So, if it doesn’t queue a work item, it should throw an exception. If it was called TryQueueWorkItem, it would be expected to return a bool with the success state.

    You should take a look at and These are from Brad’s book.

  3. But I think the point is that the failure to queue a user work item isn’t *necessarily* an exceptional condition. And whether or not it’s an error depends on what you’re doing.

    For some applications, it might be a completely common occurrence for them to dump so much work into the thread pool that it eventually says "OK, I’m full now" and for the application to respond by throttling back. This doesn’t need to be an error. It’s not that different from the way some networking systems work: sending data in small bursts often doesn’t block, because the system can queue up a number of outbound requests in buffers; but if you start to send high volumes, the system can exert backpressure by blocking further sends.

    That seems to be the style of operation that the API design is suggesting.

    It is of course completely possible that the API design is in fact wrong. :)  It’s just not self-evidently wrong.

  4. In part 2, I showed a base class for DataModels. In this post, I will describe a sample implementation….

  5. In part 2 , I showed a base class for DataModels. In this post, I will describe a sample implementation.