Просто для того, чтобы с чего-нибудь начать разговор и подойти к сегодняшней теме я бы хотел немного напомнить историю развития платформы .NET и языка C# . Это даст нам понять то, как же мы докатились до такой жизни. В целом, нас интересует два последних релиза языка C# , которые и дали основной толчок асинхронному программированию на платформе .NET . И да, вам не послышалось и я не оговорился, именно два последних релиза сделали асинхронное программирование таким, каким мы его знаем сегодня, а не один последний релиз. В C# 4.0 ( а точнее в .NET Framework 4.0) появилась TPL , а в C# 5.0 (и .NET 4.5 ) эта модель асинхронного программирования стала повсеместной; и не последнюю роль в этом вопросе сыграли новые возможности языков C# и VB . NET . Давайте посмотрим, к чему же мы стремились.
С одной стороны, асинхронное программирование на платформе .NET существовало с самой первой ее версии (в виде так называемой Asynchronous Programming Model ), а с другой стороны асинхронное программирование всегда было на порядок сложнее с точки зрения реализации, отладки и сопровождения, по сравнению с синхронной версией. Основная же цель новых «асинхронных» возможностей языка C# была направлена на «унификацию» синхронного и асинхронного программирования. Решить проблему асинхронности путем добавления пары ключевых слов в тело и заголовок методов, чтобы сделать их асинхронными. И это просто прекрасно, но сразу же после выхода этого дела в свет стало ясно, что у этой простоты есть своя цена! На самом деле, я могу
TODO: выделить ключевые слова и Async , чтобы изменения были более видны
Главная цель моего выступления заключается в том, чтобы немного сместить акцент с языковых конструкций, которые появлись в C# и VB с выходом VS2012 . Разобраться с новыми ключевыми словами не требует больших усилий, однако для написания нормального асинхронного кода все равно нужно понимать, что происходит внутри. О новых языковых возможностях не рассказывал и не писал только ленивый. В любой новой книге по языку C# , в любом выступлении на конференции об этом говорится. Но уже сейчас становится понятно, что та простота, которой так хотели добиться разработчики обладает и негативной стороной. Единственной сессией на MVP саммите в этом году было выступление Стивена Тауба и Лушиана Вишика о проблемах async void методах. Это первый такой звоночек, который говорит, что слишком многие относятся к новым возможностям слишком уж легкомысленно. Поэтому сегодня я хочу дать основные понятия и концепции, которые стоит изучить более подробно, чтобы стать асинхронным гуру!
Абстракции текут и чтобы понимать что-то нам нужно разбираться на один уровень абстракции ниже!
Обязательно сказать и продумать про разные типы приложений!!
Когда речь заходит за UI потоки, то любой join асинхронной операции может привести к deadlock -у. В этом случае работает следующее правило: если вы начали использовать асинхронные операции, то их следует продолжать использование, а не ожидать их завершения (явно или неявно).
Что будет в этом случае? Будет ли проброшено исключение первой задачи, второй задачи, обеих задач в виде AggregateException ?
Очень печально, но в данном случае наружу вылетит лишь первое из возникших исключений! Я так и не смог добиться получения наружу обоих исключений!!
Principles Async void is a “fire-and-forget” mechanism... The caller is unable to know when an async void has finished The caller is unable to catch exceptions thrown from an async void (instead they get posted to the UI message-loop) Guidance Use async void methods only for top-level event handlers (and their like) Use async Task-returning methods everywhere else When you see an async lambda, verify it
Найти рисунок и цитату типа «тяп-ляп и в продакшн»