将异步添加到方法签名是否是一项重大更改? [英] Is adding async to a method signature a breaking change?

问题描述

在解决有关使用异步/等待量的问题时，即所有方法是否应返回Task?"，这个答案，MatíasFidemraizer声称，即使您的方法当前仅执行同步处理，它仍应返回任务，因此，如果稍后使它执行异步处理，您可以将其转换为实际的异步操作，而无需执行任何操作影响整个代码库".这是有道理的，但是如果我实际上正在等待某些东西，则必须在方法签名中添加async.因此，我们正在谈论的是:

In addressing a question about how much to use async/await, i.e. "should all methods return Task?", the author of this answer, Matías Fidemraizer, claims that, even if your method currently only does synchronous stuff, it should still return a task so if you make it do async stuff later, "you can turn it into actual async operations without affecting the entire code base". That makes sense, but if I'm actually awaiting something, I have to add async to the method signature. So we're talking about going from:

public Task WhateverAsync()
{
    return Task.FromResult(true);
}

到

public async Task WhateverAsync()
{
    return await AwaitableSomething();
}

在方法签名中添加async是一项重大更改吗?

Is adding async to a method signature a breaking change?

推荐答案

即使您的方法当前仅执行同步操作，它仍应返回任务

even if your method currently only does synchronous stuff, it should still return a task

我不同意.如果您的方法是同步的，则它应该具有同步API.如果您的方法是异步的，则它应该具有异步API.

I disagree. If your method is synchronous, then it should have a synchronous API. If your method is asynchronous, then it should have an asynchronous API.

但是，我同意同步方法应该具有Task返回签名如果是在接口/基类中定义的，并且将来的实现/替代可能要使用await.

However, I would agree that synchronous methods should have a Task-returning signature if they are defined in an interface / base class and there is a decent possibility that future implementations / overrides may want to use await.

向方法签名添加异步是一项重大更改吗?

Is adding async to a method signature a breaking change?

仅添加async?不它不是.考虑接口中定义的Task返回方法的情况:可以在有或没有async的情况下实现.

Just adding async? No, it is not. Consider the case of a Task-returning method defined in an interface: it may be implemented either with or without async.

但是，可能有一些语义差异，正如我在博客中所描述的.最值得注意的是，异常处理是不同的.如果不小心，天真的同步实现可能会直接引发异常，而不是返回错误的任务.一旦使用该方法async，该异常将使任务出错，并且不再直接抛出该错误.

However, there are some possible differences in semantics, as I describe on my blog. The most notable is that the exception handling is different. If you're not careful, a naive synchronous implementation could throw an exception directly, rather than returning a faulted task. As soon as you make that method async, the exception would be faulting a task, and no longer thrown directly.

因此，这实际上是一个关于语义可能发生变化的问题.我认为天真的同步语义是错误的，因为该方法具有异步签名.例如，同步方法具有异步签名，因此调用方可以假定它将捕获异常并返回错误的任务，这是合理的.因此，如果同步实现具有这些(容易引起的)错误，那么从技术上来说，添加async 将会是一项重大突破.

So, it's really a question about possible changes in semantics. I would argue that the naive synchronous semantics were wrong, since the method had an asynchronous signature. E.g., the synchronous method has an asynchronous signature, so it is reasonable for callers to assume that it will catch exceptions and return a faulted task. So, if the synchronous implementations have these (easy-to-cause) bugs, then adding async would technically be a breaking change.

这篇关于将异步添加到方法签名是否是一项重大更改?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！