У меня есть интерфейс с некоторыми асинхронными функциями. Некоторым классам, реализующим интерфейс, нечего ждать, а некоторые могут просто выбросить. Все предупреждения немного раздражают.
Если не использовать ожидание в асинхронной функции.
Можно ли подавить сообщение?
public async Task<object> test()
{
throw new NotImplementedException();
}
предупреждение CS1998: в этом асинхронном методе отсутствуют операторы ожидания, и он будет выполняться синхронно. Рассмотрите возможность использования оператора await для ожидания неблокирующих вызовов API или await Task.Run (...) для выполнения работы, связанной с процессором, в фоновом потоке.
c#
asynchronous
Саймон
источник
источник
Ответы:
Task
Думаю, методы возвращаются .async
это деталь реализации, поэтому ее нельзя применить к методам интерфейса.В этих случаях вы можете воспользоваться тем фактом, что
async
это деталь реализации.Если нечего
await
, то можно просто вернутьсяTask.FromResult
:В случае с метанием
NotImplementedException
процедура более многословна:Если у вас есть много методов
NotImplementedException
(что само по себе может указывать на то, что некоторый рефакторинг на уровне дизайна был бы хорош), вы могли бы обернуть многословие в вспомогательный класс:Вспомогательный класс также уменьшает мусор , что GC в противном случае пришлось бы собирать, так как каждый метод с тем же типом возвращаемого значения может поделиться своим
Task
иNotImplementedException
объекты.У меня есть несколько других примеров типа «константа задачи» в моей библиотеке AsyncEx .
источник
Task
. Вместо этого ваш метод выбросит еще до того, как у него появится возможность создатьTask
. Я действительно думаю, что лучший шаблон - определитьasync
метод безawait
операторов. Это гарантирует, что весь код внутри метода будет рассматриваться как частьTask
.await Task.FromResult(0);
в свой метод. Это не должно иметь значительного влияния на производительность (в отличие от Task.Yield ()).return Task.CompletedTask;
- самое простое из всех.Другой вариант, если вы хотите сохранить простоту тела функции и не писать код для ее поддержки, - просто подавить предупреждение с помощью #pragma:
Если это достаточно часто, вы можете поместить инструкцию disable в верхней части файла и пропустить восстановление.
http://msdn.microsoft.com/en-us/library/441722ys(v=vs.110).aspx
источник
Другой способ сохранить ключевое слово async (если вы хотите его сохранить) - использовать:
После заполнения метода вы можете просто удалить оператор. Я использую это часто, особенно когда метод может чего-то ожидать, но на самом деле не все реализации.
источник
Task.Run
вызове.Task.CompletedTask
больше не существует.Task.FromResult
лучшим ответом. Впрочем, если вы которые собираются бросить исключение, кажется , еще один ответ пришел в игру по поводуTask.FromException
создания этого никогда не идеальное решение. Вы бы согласились?Существует разница между решениями, и, строго говоря, вы должны знать, как вызывающий абонент будет вызывать асинхронный метод, но с шаблоном использования по умолчанию, предполагающим ".Wait ()" в результате метода - " return Task.CompletedTask " - лучшее решение.
Примечание:
FromResult
нельзя сравнивать напрямую.Код теста:
}
источник
#pragma
кажется, что это связано с накладными расходами. Наверное, столько же накладных расходов, как если бы вместо возвратаCompletedTask
вы создали и завершилиAsyncOperation
. Было бы неплохо иметь возможность сказать компилятору, что можно пропустить это, когда метод в любом случае работает синхронно.Task.CompletedTask
похоже наTask.FromResult
? Было бы интересно узнать - я ожидаю, что FromResult будет наиболее аналогичным и по-прежнему лучшим исполнителем, если вам нужно вернуть значение.Я знаю, что это старый поток, и, возможно, это не будет иметь правильного эффекта для всех случаев использования, но следующее как можно ближе к возможности просто выбросить NotImplementedException, когда я еще не реализовал метод, без изменения сигнатуры метода. Если это проблематично, я был бы счастлив узнать об этом, но для меня это не имеет значения: я все равно использую это только во время разработки, поэтому то, как оно работает, не так уж важно. Тем не менее, я был бы рад услышать, почему это плохая идея, если это так.
Вот тип, который я добавил, чтобы это стало возможным.
источник
Так же, как обновление ответа Стивена, вам больше не нужно писать
TaskConstants
класс, так как есть новый вспомогательный метод:источник
Если вы уже ссылаетесь на Reactive Extension, вы также можете:
Reactive и async / await великолепны сами по себе, но они также хорошо работают вместе.
В комплект входят:
источник
Это могло произойти cs1998 ниже.
Тогда вы можете изменить ниже.
источник
Вы можете попробовать это:
источник
Попробуй это:
[System.Diagnostics.CodeAnalysis.SuppressMessage("Await.Warning", "CS1998:Await.Warning")]
См. Https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.codeanalysis.suppressmessageattribute?view=netframework-4.7.2
источник
Если вам нечего ждать, верните Task.FromResult
источник
Вот несколько альтернатив в зависимости от подписи вашего метода.
источник
источник
Вы можете удалить ключевое слово async из метода и просто вернуть Task;
источник