StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
7343485
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
7
CommunityOwnedDate
CreationDate
2011-09-08T05:28:55.603
FavoriteCount
0
LastActivityDate
2011-09-08T05:28:55.603
LastEditDate
LastEditorUserId
0
OwnerUserId
22656
ParentId
7343211
PostTypeId
2
Score
77
ViewCount
0
LastEditorDisplayName
text
Body
<blockquote> I am trying to avoid any exceptions when cancelling. </blockquote> You shouldn't do that. Throwing <code>OperationCanceledException</code> is the idiomatic way that "the method you called was cancelled" is expressed in TPL. Don't fight against that - just expect it. It's a good thing, because it means that when you've got multiple operations using the same cancellation token, you don't need to pepper your code at every level with checks to see whether or not the method you've just called has actually completed normally or whether it's returned due to cancellation. You could use <a href="http://msdn.microsoft.com/en-us/library/system.threading.cancellationtoken.aspx"><code>CancellationToken.IsCancellationRequested</code></a> everywhere, but it'll make your code a lot less elegant in the long run. Note that there are two pieces of code in your example which are throwing an exception - one within the task itself: <pre><code>cancelToken.ThrowIfCancellationRequested() </code></pre> and one where you wait for the task to complete: <pre><code>task.Wait(cancellationToken.Token); </code></pre> I don't think you really want to be passing the cancellation token into the <code>task.Wait</code> call, to be honest... that allows other code to cancel your waiting. Given that you know you've just cancelled that token, it's pointless - it's bound to throw an exception, whether the task has actually noticed the cancellation yet or not. Options: <ul> <li>Use a different cancellation token (so that other code can cancel your wait independently)</li> <li>Use a time-out</li> <li>Just wait for as long as it takes</li> </ul>
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POCancelling a Task is throwing an exception
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USJon Skeet
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. COJon cost of entering try is higher than if(IsCancellationRequested). in normal project you would ignore that for the benefits of what you've said. however if you want avoid extra cost at any cost then you effectively cannot use cancellation and need to build it by hand........ I am sure they could have implemented property something ThrowIfCancelled for those who wants exceptions. But no.
 singulars
 PostPostId
 PO
 UserUserId
 USBoppity Bop
2. CO@Bobb: Note that both the property (`IsCancellationRequested`) and the method (`ThrowIfCancellationRequested`) *are* both implemented in the TPL. So in the *very extreme cases* where you really don't want the cost of an exception, you can avoid it - but I wouldn't do so without *evidence* that it was actually a bottleneck in the system.
 singulars
 PostPostId
 PO
 UserUserId
 USJon Skeet

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.