Здравствуйте, Kolesiki, Вы писали:

K>Но вот async?...
K>Пусть это будет команда Save. Мы нажали, асинхронно вышли из метода, куда-то даже полезли нажимать другие команды, а save всё ещё работает! Хуже того — у неё могут возникнуть проблемы!
K>Ну и вот какой смысл "не ждать завершения команды", если всё равно тебе прилетит по лбу? Хуже того — ты понадеялся на УСПЕШНЫЙ сэйв, а документ уже испортил!

1) испортить документ — это логическая ошибка, безотносительно реализации. Это значит, что надеяться на успешный сэйв очевидно, нельзя. Но это не значит, что он может быть асинхронным.

2) подвиснуть на 30 секунд сохраняя документ не отрисовывая окно — не очень дружественно к пользователю. Это надо решать.

3) не разгребать очередь сообщений вообще в течении 30 секунд и не кооперировать с системой как она просит — это еще одна логическая ошибка, приводящая, к потери данных.

4) async/await лишь помогает/позволяет записать некоторые взаимодействия в их более-менее естественной форме, без зубодробильного ручного маршаллинга вызовов по потокам или превращения кода в рандомный набор кусочков реализаций и коллбэков. Но, вполне естественно, что эта фича не заботится о всех возможных и невозможных логических переходах состояний, коих в UI предостаточно. А что будет, если пока документ сохраняется — мы его изменили и опять нажали сохранение? Это всё вопросы которые программисту нужно решать, но это же не задача async/await. А то так можно и к yield return придраться.

Здравствуйте, Kolesiki, Вы писали:

K>Но вот async?...
K>Пусть это будет команда Save. Мы нажали, асинхронно вышли из метода, куда-то даже полезли нажимать другие команды, а save всё ещё работает! Хуже того — у неё могут возникнуть проблемы!
K>Ну и вот какой смысл "не ждать завершения команды", если всё равно тебе прилетит по лбу? Хуже того — ты понадеялся на УСПЕШНЫЙ сэйв, а документ уже испортил!

1) испортить документ — это логическая ошибка, безотносительно реализации. Это значит, что надеяться на успешный сэйв очевидно, нельзя. Но это не значит, что он не может быть асинхронным.

2) подвиснуть на 30 секунд сохраняя документ не отрисовывая окно — не очень дружественно к пользователю. Это надо решать.

3) не разгребать очередь сообщений вообще в течении 30 секунд и не кооперировать с системой как она просит — это еще одна логическая ошибка, приводящая, к потери данных.

4) async/await лишь помогает/позволяет записать некоторые взаимодействия в их более-менее естественной форме, без зубодробильного ручного маршаллинга вызовов по потокам или превращения кода в рандомный набор кусочков реализаций и коллбэков. Но, вполне естественно, что эта фича не заботится о всех возможных и невозможных логических переходах состояний, коих в UI предостаточно. А что будет, если пока документ сохраняется — мы его изменили и опять нажали сохранение? Это всё вопросы которые программисту нужно решать, но это же не задача async/await. А то так можно и к yield return придраться.