First chance OperationCanceledException in BlockingCollection.TryTake - by Wuzi

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 631951 Comments
Status Closed Workarounds
Type Bug Repros 1
Opened 12/16/2010 10:55:57 AM
Access Restriction Public


When running sample code below, OperationCanceledException is thrown inside the TryTake, which later gets wrapped in "false". This is a big problem for debugging if first chance exceptions are enabled, since this is a "normal" way of operating, not some error like missing file or incorrect argument.  Please cleanup so that no exceptions are thrown internally for normal execution.
Sign in to post a comment.
Posted by dav36van on 4/18/2013 at 3:11 PM
It's ridiculous not to fix this - I originally had a TryTake executing on a BlockingCollection which was throwing an exception when I set the BlockingCollection object to null as part of a cancellation method. I quickly said "oops, I should use the actual CancellationToken so that it breaks from the blocking call cleanly and improves on performance." - only to find that it just produces a different exception. So instead of an exception where the collection is null, it's an exception that the operation was cancelled.

Exceptions are costly, and furthermore it means that there is literally no difference between the sloppy option of nulling out the collection versus using the supposedly official implementation of also throwing an exception.
Posted by GPSnoopy on 7/25/2012 at 2:28 AM
I have to agree with the original poster. It's a clear violation of exception guidelines and well annoying. The fact that the same design flaw is present in SemaphoreSlim only means the latter also needs fixing.

Claiming otherwise while providing a workaround which reduce the effectiveness of exception breakpoints is "maybe" slightly misguided?
Posted by Microsoft on 2/10/2011 at 9:45 AM
I'll close the bug again, please let me know if you still have any concerns
Posted by Microsoft on 2/10/2011 at 9:43 AM
Sorry Wuzi for missing the comments when we closed the bug.

This seems to us not a bug and implementation details when we throw an catch an exceptin internally that never goes up to the user code.
I'm not considering this as a violation of the design guide lines, because it uses another type (SemaphoreSlim) which throws the exception.

You can avoid that by enable "Just my Code" from the debugging options Then in the Exception dialog Checking throwing for all CLR Exception
Posted by Wuzi on 1/27/2011 at 10:21 AM
The bug was closed without even a comment? At least state that MS does not follow its own guidelines in this specific case due to XYZ.
Posted by Alex Martsynkevich on 12/16/2010 at 12:58 PM
Although this is just a first chance exception and is caught somewhere in the entrails of mscorlib, it's annoying while debugging, and things like this usually indicate a problem to a developer. Since it is happening during normal operation it is a clear violation of your guidelines: "Do not use exceptions for normal flow of control..." (exerted here: ). Cheers!
Posted by Microsoft on 12/16/2010 at 12:37 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(