В соответствии с ошибкой это возвращает bool
:
CC.MethodThatReturnsBool()
Таким образом, вы бы сохранили его так:
bool newBool = CC.MethodThatReturnsBool();
Что, казалось бы, означает, чтонет ожидающих асинхронных операций.Упрощение:
public void Starter()
{
CC = new CustomClass();
bool b = CC.MethodThatReturnsBool();
// do something with your bool?
}
Непонятно, почему вы ожидаете await
чего-либо, и действительно может быть что-то еще, что вы не показываете, но если вызываемый вами метод является синхроннымтогда нет нужды его ждать.
Примечание: async void
очень плохая идея 1016 *.Он существует только для совместимости с обработчиками событий пользовательского интерфейса и тому подобным.Если вы пишете что-нибудь под вашим контролем, не используйте async void
.
Редактировать:
Исходя из вашего обновления вопроса, это звучит как , что здесь происходит, что у вас есть длительный синхронный процесс, который вы хотели бы не блокировать поток пользовательского интерфейса?Вы можете обернуть что-то в Task
, возможно, что-то вроде этого:
bool b = await Task.Run(() => new CustomClass().MethodThatReturnsBool());
Так что, возможно, в целом вы ищете что-то более похожее (непроверенное)?:
public async Task Starter()
{
Task<bool> newTask = Task.Run(() => new CustomClass().MethodThatReturnsBool());
// DO SOME VISUAL THINGS
bool b = await newTask;
// do something with your bool?
}
Для уточнения предыдущего пункта отметим, что общий метод теперь равен async Task
вместо async void
.Это делает Starter
само по себе ожидаемым, поскольку void иначе не будет.
В идеале , конечно, MethodThatReturnsBool
должно само по себе быть async
, если оно внутренневыполнение различных операций ввода-вывода, которые вызывают его задержку.(Как подразумевается в вашем комментарии к вышеуказанному вопросу.) Это может включать рефакторинг в других местах системы, но в долгосрочной перспективе это предпочтительный подход.