捕获TaskCanceledException并检查Task.Canceled是个好主意吗? [英] Is catching TaskCanceledException and checking Task.Canceled a good idea?

查看:116
本文介绍了捕获TaskCanceledException并检查Task.Canceled是个好主意吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们团队中有些人真的很喜欢使用异步 Task 进行编码。有时他们喜欢使用 CancellationToken 参数。

There are some people on my team who really love coding with async Task. And sometimes they like to use CancellationToken parameters.

我不确定的是我们是否应该作为一个团队使用这种样式的代码(A):

What I'm unsure about is whether we should as a team be using this style of code (A):

async Task<someObject> DoStuff(CancellationToken t)
{
    while (!t.IsCanceled)
    {
        try {
            Task.Delay(5000, t);
        }
        catch (AggregateException e) // or is it TaskCanceledException or OperationCanceledException? I don't know? :)
        {
        }
        // poll something, return someObject, or null
    }
    return null;
}

这显然意味着调用方可能必须自己检查取消令牌以确定是否继续处理,它们可能必须处理空的retVal:

This obviously means the caller probably has to check the cancellation token themselves to determine whether to continue processing, and they might have to handle null retVals:

var retVal = await DoStuff(token);
if (token.IsCanceled) { ... }

但是,如果我们采用第二种依赖TaskCanceledException的代码(B):

However, if we adopt a second style of code (B) that relies on TaskCanceledException:

async Task<someObject> DoStuff(CancellationToken t)
{
    while(true)
    {
        Task.Delay(5000, t);
        // poll something, return someObject, or null
    }
}

实现代码肯定更简单-调用方可以选择是否适当地处理异常...但是我不禁担心调用方可能会忘记 TaskCanceledException是什么他们必须担心,并且由于它们未捕获这些异常(在前台或后台线程上)而导致进程可能崩溃。

The implementation code is definitely simpler - and the caller has the option of handling the exception or not, as appropriate... but I can't help worrying that callers might forget that TaskCanceledException is something they have to worry about, and processes may crash as a result of them not catching these exceptions (on foreground or background threads).

因此,我过于乐观的措辞是:您认为每个人始终应该使用的最佳样式是什么,为什么? :)

So, my overly optimistically phrased question is: which do you think is the best style that everyone should always use, and why? :)

推荐答案

在.Net框架中,当您传递 CancellationToken 作为参数您将获得 TaskCanceledException 。我不反对这样做并创建自己的设计模式,因为熟悉.Net的人会熟悉您的代码。

In the .Net framework itself when you pass a CancellationToken as a parameter you will get back a TaskCanceledException. I would not go against that and create my own design pattern because people who are familiar with .Net will be familiar with your code.

我的指导方针是:取消令牌是应该处理 TaskCanceledException 的令牌,因此如果您在方法中使用 CancellationToken 出于您自己的原因,请继续使用 try-catch 块。 但是,如果您将令牌作为参数,则抛出异常

My guideline is this: The one that cancels the token is the one that should handle the TaskCanceledException, so If you're using a CancellationToken inside your method for your own reasons, go ahead and use a try-catch block. But if you get the token as a parameter, let the exception be thrown.

这篇关于捕获TaskCanceledException并检查Task.Canceled是个好主意吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆