Здравствуйте, Shmj, Вы писали:
S>Конечный итог ошибки может быть таким:
Завтра мода на GUI поменяется, и список твой будет звучать по-другому.
В конечном итоге, сообщение об ошибке, как бы оно не выглядело, должно нести следующую информацию:
1. Чего, собственно, хотят от пользователя? Попробовать еще раз? Исправить ошибки ввода? Подёргать провод? Перезагрузиться? Позвать старщего? Позвонить в техподдержку? Отнести компутер в ремонт?
2. Что случилось с его запросом? Он вообще не исполнен? Он исполнен наполовину? Деньги ушли, но пылесос не приедет?
3. Если есть негативные последствия, как их исправить?
4. Насколько всё это серьезно? Само рассосётся?
Ну, и кроме того, должна сохраняться подробная информация для профессионального разбора полётов.
Здравствуйте, Sinclair, Вы писали:
S>Нет, зачем? Это просто сессионный токен, который выдан вам сервисом аутентификации.
И? Вы его сбросили и установили в другой — далее что? Автоматом все запросы отменятся что ли?
S>>Как вы представляете прекращение существования пользовательской сессии? Убить процесс приложения? S>Самый простой вариант — да, убить процесс
Вот в этом у вас и проблема... В 2025 году так никто не делает. Программа продолжает работать, просто переходит на страницу входа — вот в чем фишка.
Понимаете ли что реальность — она другая. По логике вещей — пользователь вышел — и все должно схлопнуться, исчезнуть, задиспозится. Но нет — так нельзя. Программа по прежнему работает.
S>>Но нет же, при выходе приложение не убивается а продолжает работать — просто переходит на страницу входа. Тогда что же? S>Тогда закрыть все формы и освободить связанные с ними структуры данных, в которых используется сессионный токен.
Вот именно что:
1. Закрыть все формы.
2. Обнулить все состояния.
3. Оборвать все запросы и длительные операции.
Не просто формы — сейчас в формах никто данные не хранит, еще раз вам говорю — данные изменяются отдельно — и при изменении даных несколько форм может обновиться.
Далее, ок. Обнулили данные. А как быть если уже вызвана асинхронная функция, которая делает несколько запросов к серверу? После каждого запроса вам нужно что? Правильно, проверять актуален ли пользователь и если НЕТ — то что? Херачить запросы далее или?
S>>Вы когда-нибудь реально меняли? У вас есть два аккаунта разных? Или просто верите в это? S>Конечно менял. Там, если что, есть режим с "демо аккаунтом".
Так дело вот в чем. Чтобы эта ошибка проявилась — нужно не простои изменить пользователя. Нужно чтобы первый пользователь запустил некую длительную операцию, которая выполняется дольше чем вход/выход из аккаунта. Это трудноуловимые ошибки и тестеры их не обнаружат да и пользователи очень редко когда столкнуться.
Здравствуйте, Быдлокодер, Вы писали:
Б>Как правило в больших приложениях используются собственные объекты HttpRequest (например, в виде обверток над стандартными или в виде "перехватчиков"). При отправке запроса всё равно передается сессионный токен, как уже писал Sinclair, вот в ответе и надо проверить, что токен, который использовался при отправке запроса всё еще равен текущему токену — обрывать ничего не надо, достаточно игнорировать ответ или не делать саму отправку, если у вас внутренняя очередь. Или же сравнить UserID (в зависимости, что надежнее, если токены могут обновляться периодически). Б>Ключевая идея, что это как правило делается в одном месте прозрачно, а не разбросано по всему клиентскому коду.
OperationCanceledException в среде .net. Это то, о чем я писал в самом начале.
Б>Кстати, и даже этого не придется делать скорее всего, т.к. при смене пользователя у тебя уничтожатся все экраны, обнулится весь state (если он был), поэтому асинхронные ответы ничего не смогут обновить, потому что там null условно говоря. Экран и стейт под нового пользователя будет создан заново, ссылки будут отличаться, поэтому как правило (если пишешь каноническое Web-приложение на популярном фреймворке) не надо беспокоиться, что из асинхронной функции у тебя обновится экран или стейт старыми данными.
Речь про дектопные/моб. приложения. В сетевых проще — там один запрос 1 ответ.
А в десктопных нередко состояние регают в IoC-фреймворке и для многих глобальных форм оно существует на протяжении всей жизни приложения.
Б>И про это тоже Sinclair в начале ветки писал. Б>В целом ваша дискуссия похожа на разговор опытного архитектора с начинающим программистом. Лучше сосредоточиться на том, чтобы подумать, как реализовать то, о чем говорит опытный архитектор, вместо того, чтобы загружать его вопросами кодирования, как написать асинхронный обработчик.
В конце до него наконец дошла идея, которую он не мог понять — что за исключение такое, которое не нужно обрабатывать. Ему привычнее .Net — у меня то стек технологий огромный и я как бы вижу самую суть. Но для него нужно назвать ключевое слово OperationCanceledException.
Здравствуйте, Shmj, Вы писали:
S>Задумался об идеологически правильной обработке ошибок (исключительных ситуаций) в приложениях для обычных пользователей.
...
Здравствуйте, Shmj, Вы писали:
S>Задумался об идеологически правильной обработке ошибок (исключительных ситуаций) в приложениях для обычных пользователей
У Вас ошибка: п. 3 пропал.
Вообще, большая часть того, что Вы описали, это не исключительные ситуации, а вполне обычный flow, о котором должен думать ещë аналитик на этапе постановки задачи.
S>Благо что все эти проблемы возникают не так часто, можно об этом не думать, иначе архитектура усложняется на порядок.
Архитектура усложняется не от частоты ошибок, а от того, какие гарантии бизнес-операций мы хотим получить.
Здравствуйте, Pzz, Вы писали:
Pzz>Завтра мода на GUI поменяется, и список твой будет звучать по-другому.
Нет, это не зависит от GUI никаким образом. Более того — часть пунктов не применима к GUI — а только к фоновым сервисам.
Pzz>В конечном итоге, сообщение об ошибке, как бы оно не выглядело, должно нести следующую информацию: Pzz>1. Чего, собственно, хотят от пользователя? Попробовать еще раз? Исправить ошибки ввода? Подёргать провод? Перезагрузиться? Позвать старщего? Позвонить в техподдержку? Отнести компутер в ремонт?
Очень важен вариант обработки ошибки вот какой, копирую:
Если изменился пользователь а некая операция продолжила выполняться и завершилась после смены пользователя — то это не ошибка, это штатное поведение. Но при этом нельзя применять результаты данной операции — нужно сгенерить исключение. Но! Пользователю и даже в лог вносить это исключение смысла нет, т.к. ситуация штатная и доп. решения не треубет.
Т.е. важно уметь оборвать операцию в процессе, но при этом не тревожить пользователя лишними оповещениями, т.к. это штатная ситуация.
Pzz>2. Что случилось с его запросом? Он вообще не исполнен? Он исполнен наполовину? Деньги ушли, но пылесос не приедет?
Тут не только что случилось. Допустим нет интернета. И что? Программа пытается сделать некую фоновую задачу — не получилось. Сообщать пользователю? Ведь он может проверить WiFi-роутер свой или оплатить задолженность по интернету провайдеру. Не сообщим — плохо. Но при этом дублировать сообщение о том что интернета нет каждые 3 секунды, доставать пользователя — так же плохо.
Читайте внимательно пункты — там не от балды а опыт 20 лет разработки.
Pzz>3. Если есть негативные последствия, как их исправить?
Если мы знаем как исправить — то можно исправить и без того, чтобы беспокоить пользователя.
Пробуйте практические примеры подобрать.
Pzz>4. Насколько всё это серьезно? Само рассосётся?
Нет сети, сервер не доступен — это, возможно, рассосется. Поврежден файл данных — уже усё. Не так много вариантов.
Pzz>Ну, и кроме того, должна сохраняться подробная информация для профессионального разбора полётов.
А вот это уже можно не отображать пользователю а отправлять разработчику в удаленный лог.
Здравствуйте, Sinclair, Вы писали:
S>Вот это и есть дизайн в стиле безумного шляпника, который создаёт вам проблемы.
Говорите конкретно что не так.
S>Пока что вы описали ровно вариант "получить результат запроса". Если пользователь отключился — всё, результат ему не нужен.
Он вышел, но программу не закрыл — старые операции продолжают работать. Механизма отмены нет.
S>Зачем вы берётесь записывать этот результат в какие-то таблицы? Пользователь явно выразил своё намерение завершить сессию. Нужно ли извещать сервер о том, что результат не нужен — дело вкуса.
Весь вопрос в том — как делать отмену. Будете ли вы встраивать в каждый сетевой запрос возможность отмены?
S>>Какая тут может быть атомарность? S>Очень простая. Но детали сильно зависят от того, что именно делает приложение. С учётом окружающих рассуждений, велики шансы на то, что вы вместо одного из двух типовых паттернов изобрели ещё какое-то безумие.
Атомарность может быть при записи в базу. А когда внешний вызов — атомарности быть не может, разве что внешний сервис это предусмотрел — но сразу проблема двух генералов, которая неразрешима в принципе.
S>Поэтому советы по реализации давать трудно. S>Остаётся только повториться: вы делаете какую-то дичь, именно поэтому никакие типовые решения вам не подходят. Ни в какой области. Ни в области персистенса, ни в области асинхронного программирования, ни в области обработки ошибок.
Так напишите как вы решите задачу:
1. Пользователь сделал запрос к серверу от имени Вася.
2. Пока идет запрос — пользователь Вася вышел и зашел под пользователем Петя. Программу не останавливали.
3. Пришел ответ запрос, но теперь текущий пользователь — Петя.
4. ?
Здравствуйте, Sinclair, Вы писали:
S>>Весь вопрос в том — как делать отмену. Будете ли вы встраивать в каждый сетевой запрос возможность отмены? S>Я же вам вроде бы объяснял, что делать с отменой. S>1. Не делать её вообще. Нет никакой разницы, вышел пользователь, или отключился, или у него на клиенте пропало питание. Действие на стороне сервера дорабатывает до конца. S>2. Делать отмену на основе транзакционности. См. пример с MS SQL Server.
Так речь о действии на стороне клиента — у клиента своя база.
S>>Атомарность может быть при записи в базу. А когда внешний вызов — атомарности быть не может, разве что внешний сервис это предусмотрел — но сразу проблема двух генералов, которая неразрешима в принципе. S>Поэтому придумали REST.
И как он решит задачу, которая не разрешима даже в теории?
S>Внезапно оказывается, что если научиться обрабатывать одну из этих ситуаций, то автоматически получится ответ на все эти ситуации, и, заодно, на все более сложные сценарии вроде придуманного вами выше. S>И способ — очень простой: S>1. Пишем в локальную базу "мы собираемся сделать к серверу вот такой запрос" (атомарно) S>2. Делаем запрос S>3. Получив ответ на запрос, пишем в базу "на запрос получен вот такой ответ" (атомарно).
S>0. При старте системы, поднимаем из локальной базы список всех запросов, которые прошли через п.1 и не прошли через п.3. Повторяем для всех их них п.2 и 3.
1. Тебе нужно проверить что текущая открытая база (а это десктопное или моб. приложение) — та же самая, того же пользователя. Что если пользователь другой?
2. Результат запроса нужно не только сохранить в базе, но и применить на форме. Пользователь нажал на кнопку — делаем запрос к серверу, обновляем таблицу, отображаем на форме. Если пользователь изменился (но форма все так же доступна через IoC глобально) — то что?
Здравствуйте, Sinclair, Вы писали:
S>>А есть же другие архитектуры — как flutter_bloc. Блок и его состояние хранятся отдельно — форму закрыли, а блок глобально зареган. S>Это не flutter виноват в том, что у вас в голове каша. Форму закрыли => нет и вопроса о том, как обновить её состояние после окончания асинхронного запроса.
В современных приложениях ты обновляешь не форму а состояние. При этом может сразу несколько форм обновиться.
S>>Но дело даже не в этом. Даже в том же WinForms — вы можете сделать глобальное событие, которое оповестить сразу N открытых форм. Так вот — прежде чем оповещать — нужно проверить что пользователь тот же самый. S>Что такое "оповещать"? Зачем это вообще делать?
Чтобы все было интерактивно — событие произошло — все формы, которые связаны с этим событием — мгновенно под него подстроились.
Забывайте дедовские технологии, когда событие было привязано к одной форме.
S>>Боле того — запрос к серверу может быть не один а много S>Вот именно. S>>- так вот, после первого мы уже можем знать что пользователь изменился и далее нет смысла делать запросы. Как оборвать процесс? S>Перестаньте мыслить категориями "пользователь изменился". Забудьте об этом. Вы же видите, что S>а) в вашей парадигме возникают проблемы S>б) ни у кого другого таких проблем не возникает
Возникают — у многих. Но многим пофиг — нет стройной идеологии.
Либо решают как вы — что не может быть удобства в виде интерактивного обновления множества форм. Т.е. отказ от удобств. Либо забивают на то что такое интерактивное обновление очень редко но метко может внести проблемы, о которых сразу не думаешь.
S>Посмотрите на то, как сделано примерно 100% софта. S>1. Как правило, нет никакой локальной базы. Нет базы — нет проблем. Банковские приложения, госуслуги, авиасейлз, покупка билетов в театр и прочее — прекрасно живут без локальных баз и фоновых запросов
Вы в каком году живете? Везде даже у каждого сайта есть локальная база на сегодня.
S>2. Если есть локальная база, то, как правило, она является либо репликой фрагмента глобальной базы, либо используется для детерминистического управления состоянием. В обоих случаях всё работает вполне простым и предсказуемым образом.
Ну вот вам и предсказуемым — пользователь изменился и привет. Просто обычно об этом не думают, т.к. проблема возникает редко и тестеры особо даже не тестируют.
Здравствуйте, Sinclair, Вы писали:
S>>Чтобы все было интерактивно — событие произошло — все формы, которые связаны с этим событием — мгновенно под него подстроились. S>Прекрасно. Как событие, так и формы существуют только в контексте "пользовательской сессии". Если пользователь отключился — всё, нет ни форм, ни оповещений от "предыдущего" пользователя. S>Пока вы этого не поймёте, будете страдать.
Очень хорошо, здорово. А теперь потрудитесь объяснить что такое "пользовательская сессия" в контексте десктопного приложения. Что за зверь такой? Быть может это что-то типа отдельного процесса на уровне операционной системы?
Как вы представляете прекращение существования пользовательской сессии? Убить процесс приложения?
Но нет же, при выходе приложение не убивается а продолжает работать — просто переходит на страницу входа. Тогда что же?
S>>Ну вот вам и предсказуемым — пользователь изменился и привет. Просто обычно об этом не думают, т.к. проблема возникает редко и тестеры особо даже не тестируют. S>Да кто вам такой бред сказал? Конечно же тестируют. Просто никто не делает приложения так, как вы — где "база" независима от "пользователя", и от обоих независимы "оповещения". S>Попробуйте, скажем, сменить пользователя в приложении Альфа-банка. И посмотрите, действительно ли придёт оповещение об исполнении перевода от "предыдущего" пользователя, и смешаются ли балансы счетов Васи и Пети.
Вы когда-нибудь реально меняли? У вас есть два аккаунта разных? Или просто верите в это?
Здравствуйте, Shmj, Вы писали:
S>И? Вы его сбросили и установили в другой — далее что? Автоматом все запросы отменятся что ли?
Логично всем запросам, у которых есть cancellation token, выдать cancel.
Тех, у которых нету — надо просто игнорировать их результат. Всё, пользователь ушёл, результат запроса уже нерелевантен.
И всё это делается в процессе логаута. Пользователь пытается выйти из системы — приложение дожидается окончания (либо завершения, либо отмены) всех асинхронных запросов.
Как раз для того, чтобы не было вопроса, "а чо делать, когда Вася проснулся, а голова — в тумбочке".
S>Вот в этом у вас и проблема... В 2025 году так никто не делает. Программа продолжает работать, просто переходит на страницу входа — вот в чем фишка.
У меня как раз проблем нет. S>Понимаете ли что реальность — она другая. По логике вещей — пользователь вышел — и все должно схлопнуться, исчезнуть, задиспозится. Но нет — так нельзя. Программа по прежнему работает.
Так это же ваша программа. Как сделаете — так и будет. Вот, например, microsoft office позволяет как залогиниться в онлайн-аккаунт, так и сделать sign out. При этом никаких "асинхронных процессов" не остаётся.
S>>>Но нет же, при выходе приложение не убивается а продолжает работать — просто переходит на страницу входа. Тогда что же? S>>Тогда закрыть все формы и освободить связанные с ними структуры данных, в которых используется сессионный токен.
S>Вот именно что:
S>1. Закрыть все формы. S>2. Обнулить все состояния. S>3. Оборвать все запросы и длительные операции.
Всё верно. S>Не просто формы — сейчас в формах никто данные не хранит, еще раз вам говорю — данные изменяются отдельно — и при изменении даных несколько форм может обновиться.
Ну так и в чём проблема?
S>Далее, ок. Обнулили данные. А как быть если уже вызвана асинхронная функция, которая делает несколько запросов к серверу? После каждого запроса вам нужно что? Правильно, проверять актуален ли пользователь и если НЕТ — то что? Херачить запросы далее или?
Ну так это вам виднее. См. п.1.
S>Так дело вот в чем. Чтобы эта ошибка проявилась — нужно не простои изменить пользователя. Нужно чтобы первый пользователь запустил некую длительную операцию, которая выполняется дольше чем вход/выход из аккаунта. Это трудноуловимые ошибки и тестеры их не обнаружат да и пользователи очень редко когда столкнуться.
Нет там никаких операций, которые выполняются дольше, чем вход/выход из аккаунта.
Такую операцию придётся специально придумать. И в ней не будет никаких чудес. Если я сделал заявку на кредит и вышел из аккаунта, а мне её завтра одобрили — в приложение ничего не придёт.
Это была бы огромная дыра в security. За такое могут и лицензию отобрать.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>И? Вы его сбросили и установили в другой — далее что? Автоматом все запросы отменятся что ли? S>Логично всем запросам, у которых есть cancellation token, выдать cancel.
Ну вот теперь вы и пришли к пониманию зачем нужно исключение, которое оборвет процесс, но его не нужно ни логировать, ни отображать. В .Net это будет — OperationCanceledException.
Так с чем вы еще не согласны то?
S>Тех, у которых нету — надо просто игнорировать их результат. Всё, пользователь ушёл, результат запроса уже нерелевантен. S>И всё это делается в процессе логаута. Пользователь пытается выйти из системы — приложение дожидается окончания (либо завершения, либо отмены) всех асинхронных запросов. S>Как раз для того, чтобы не было вопроса, "а чо делать, когда Вася проснулся, а голова — в тумбочке".
А с чем вы спорите? Именно это я сказал в самом начале. И ушло много сообщений, чтобы вы, наконец, поняли идею.
S>Так это же ваша программа. Как сделаете — так и будет. Вот, например, microsoft office позволяет как залогиниться в онлайн-аккаунт, так и сделать sign out. При этом никаких "асинхронных процессов" не остаётся.
А где гарантия что там не остается таких процессов? Кто проверял? Какой процесс вы проверяли?
Я только что подобную ошибку словил на MacOS свежей — не мог удалить файл из корзины, т.к. он используется. Вот вам и привет.
S>>Так дело вот в чем. Чтобы эта ошибка проявилась — нужно не простои изменить пользователя. Нужно чтобы первый пользователь запустил некую длительную операцию, которая выполняется дольше чем вход/выход из аккаунта. Это трудноуловимые ошибки и тестеры их не обнаружат да и пользователи очень редко когда столкнуться. S>Нет там никаких операций, которые выполняются дольше, чем вход/выход из аккаунта.
А кто дает такую гарантию? Это должно быть выражено в цифрах — сколько секунд выходит из системы пользователь и сколько секунд самая длительная из возможных операций.
S>Такую операцию придётся специально придумать. И в ней не будет никаких чудес. Если я сделал заявку на кредит и вышел из аккаунта, а мне её завтра одобрили — в приложение ничего не придёт. S>Это была бы огромная дыра в security. За такое могут и лицензию отобрать.
Здравствуйте, Marty, Вы писали:
S>>Понимаю вашу склонность приклоняться пред авторитетами — но истина в этом не нуждается. В данном случае я оказался прав и спустя несколько сообщений Sinclair это понял, теперь молчит. M>Он молчит, потому что понял, что твою тупость не пробить ничем
Ты сейчас действуешь по примативному инстинкту — поддержка соц. иерархии. Типа если ты шестеришь перед авторитетом — то якобы можешь стать бета — чистый примативизм.
Если хочешь действовать не как хомо а как сапиенс — то:
1. Объясни суть спора, с чем был не согласен Sinclair.
2. Опиши к какому выводу пришли и какое к этому отношение имеет OperationCanceledException.
Здравствуйте, Shmj, Вы писали:
S>>>Ты опять переходишь на свой конек — на личности. Давай технический ответ — о чем был спор технически? M>>Конек или нет — Синклер тебе донёс предельно ясно, всё разжевал, в рот положил
S>Ты технически можешь сказать в чем вопрос был — с чем он был не согласен?
Ты хочешь, чтобы я повторил то, что до тебя Синклер пытался донести?
Я тебе в двух словах скажу. Ты хуету какую-то спроектировал или пытаешься спроектировать
Здравствуйте, Marty, Вы писали:
M>Ты хочешь, чтобы я повторил то, что до тебя Синклер пытался донести?
Нет, ты скажи с чем Синклер конкретно был не согласен. В чем вопрос вообще был? Далее — какое к этому вопросу имеет отношение OperationCanceledException.
Попробуй напрячь мозги, перейти из категории гомо в категорию сапиенсов. Но не уверен что сможешь.
Здравствуйте, Marty, Вы писали:
S>>Нет, ты скажи с чем Синклер конкретно был не согласен. В чем вопрос вообще был? Далее — какое к этому вопросу имеет отношение OperationCanceledException. S>>Попробуй напрячь мозги, перейти из категории гомо в категорию сапиенсов. Но не уверен что сможешь.
M>Тебе нельзя ничего доказать, когда ты рогом упёрся, да и нет у меня такой нужды. Хочешь быть дураком — будь им, мешать не буду
Т.е. ты продолжаешь гнуть свою линию — вместо ответа на технические вопросы — занимаешься примативизмом? Где ответ на технический вопрос?
Здравствуйте, Marty, Вы писали:
S>>Т.е. ты продолжаешь гнуть свою линию — вместо ответа на технические вопросы — занимаешься примативизмом? Где ответ на технический вопрос? M>Тебе ответ по существу не нужен, ты всё равно с ним не согласен
Если бы ты потрудился посмотреть КАКОЙ ВОПРОС БЫЛ — то увидел бы, что мы с Синклер уже все решили и вопрос исчерпан. Но тебе лишь бы примативизм проявить — ходишь по темам выискиваешь кого можно унизить по соц. иерархии.
Задумался об идеологически правильной обработке ошибок (исключительных ситуаций) в приложениях для обычных пользователей.
Конечный итог ошибки может быть таким:
1. Подсветить поле с неверно введенными данными. Самый мягкий случай, когда ошибка ввода данных. Нужно сделать без перехода и диалогов.
2. Отобразить пользователю диалог модальный, когда ошибка важная и требует чтобы пользователь увидел.
4. Отобразить всплывающее окошко. Когда ошибка не важна, скрывать будет не верно (хотя бы для целей отладки и светлого будущего программы), но и она особо погоды не строит.
5. Перевести пользователя в оффлайн-режим. К примеру, если нет подключения, но программа может работать в оффлайн.
6. Заставить пользователя пройти повторную авторизацию (переадресовать на форму входа). Если данные аутентификации отозваны, устарели и пр. Сюда же относим прочие переадресации на формы для обязательного ввода данных (а может быть и не обязательные).
7. Просто записать данные в лог/удаленный лог.
8. Ничего не делать — проигнорить, но оборвать текущую операцию.
9. Возможно — удалить текущую базу данных ввиду ее повреждения (если база не критична) или отобразить форму невозможности продолжения работы ввиду повреждения базы.
10. Попытаться устранить проблему автоматически — как-то устаревший формат файла — провести приведение к новому формату.
Итого — дофига разных вариантов какие типы реакций могут быть.
Фактически нужно помнить что каждая КАЖДАЯ операция может либо завершиться успешно — либо с ошибкой. Причем нужно правильно отреагировать — выбрать какой из 10 вариантов применить.
Есть типовые проблемы, которые могут возникнуть в любом приложении — но очень редко и маловероятно. К примеру, что если я выйду из RSDN, но форму с сообщением не закрою. Потом войду под другим аккаунтом и отправлю сообщение. Под каким пользователем оно опубликуется — под новым или под старым? А ведь я отвечал на сообщение старого пользователя, там от его имени все. Отож. Вывод:
Каждая операция должна проверять под каким пользователем она была начала и если пользователь в процессе операции изменился — то оборвать работу (или даже откатить изменения).
Благо что все эти проблемы возникают не так часто, можно об этом не думать, иначе архитектура усложняется на порядок.
S>Конечный итог ошибки может быть таким:
S>1. Подсветить поле с неверно введенными данными. Самый мягкий случай, когда ошибка ввода данных. Нужно сделать без перехода и диалогов.
валидация
S>2. Отобразить пользователю диалог модальный, когда ошибка важная и требует чтобы пользователь увидел.
ошибка
пункт 3 где? тоже вот, пожалуйста, ошибочка закралась ))
S>4. Отобразить всплывающее окошко. Когда ошибка не важна, скрывать будет не верно (хотя бы для целей отладки и светлого будущего программы), но и она особо погоды не строит.
уведомление (тост)
S>5. Перевести пользователя в оффлайн-режим. К примеру, если нет подключения, но программа может работать в оффлайн.
это вообще из другой тематики. В большинстве случаев этого не надо либо достаточно сделать через пункты 2 или 4
S>6. Заставить пользователя пройти повторную авторизацию (переадресовать на форму входа). Если данные аутентификации отозваны, устарели и пр. Сюда же относим прочие переадресации на формы для обязательного ввода данных (а может быть и не обязательные).
редирект
S>7. Просто записать данные в лог/удаленный лог.
логгирование
S>8. Ничего не делать — проигнорить, но оборвать текущую операцию.
+пункт 2 или 4
S>9. Возможно — удалить текущую базу данных ввиду ее повреждения (если база не критична) или отобразить форму невозможности продолжения работы ввиду повреждения базы.
ОМГ что???
S>10. Попытаться устранить проблему автоматически — как-то устаревший формат файла — провести приведение к новому формату.
бизнес-логика
S>Итого — дофига разных вариантов какие типы реакций могут быть.
S>Фактически нужно помнить что каждая КАЖДАЯ операция может либо завершиться успешно — либо с ошибкой. Причем нужно правильно отреагировать — выбрать какой из 10 вариантов применить.
Итого: 1 пункт про ошибку + 1 про уведомляшку. Остальное про всякое разное стандартное полезное: логгирование, валидация и бизнес-логика
Здравствуйте, DiPaolo, Вы писали:
S>>1. Подсветить поле с неверно введенными данными. Самый мягкий случай, когда ошибка ввода данных. Нужно сделать без перехода и диалогов. DP>валидация
Ну да, обработка ошибки пользователя по месту. Можно и модальный диалог "Вы ввели неверный email" [ОК].
S>>2. Отобразить пользователю диалог модальный, когда ошибка важная и требует чтобы пользователь увидел. DP>ошибка
DP>пункт 3 где? тоже вот, пожалуйста, ошибочка закралась ))
S>>4. Отобразить всплывающее окошко. Когда ошибка не важна, скрывать будет не верно (хотя бы для целей отладки и светлого будущего программы), но и она особо погоды не строит. DP>уведомление (тост)
Красное уведомление — чтобы было понятно что есть проблема и возможно требуется решение. К примеру — временное уведомление — фоновая операция не удалась, сервер не доступен.
S>>5. Перевести пользователя в оффлайн-режим. К примеру, если нет подключения, но программа может работать в оффлайн. DP>это вообще из другой тематики. В большинстве случаев этого не надо либо достаточно сделать через пункты 2 или 4
Почему из другой? К примеру, у тебя есть некая фоновая операция по обновлению данных. Если обновление не удалось — можно отобразить пользователю — не удалось, нет подключения. Но постоянно терзать его этими сообщениями — уже не комильфо — нужно бы просто отобразить плашку — "оффлайн-режим".
S>>6. Заставить пользователя пройти повторную авторизацию (переадресовать на форму входа). Если данные аутентификации отозваны, устарели и пр. Сюда же относим прочие переадресации на формы для обязательного ввода данных (а может быть и не обязательные). DP>редирект
Так редирект то — как реакция на ошибку протухших данных доступа. Это реакция на исключительную ситуацию, т.к. в стандартном случае данные сами собой не протухают. А так сервер вернул ошибку — мы должны как-то отработать.
S>>7. Просто записать данные в лог/удаленный лог. DP>логгирование
Перехватил исключение — и залогировал в фоновом сервисе, т.к. клиент не видит формы никакой, это происходит без клиента. Нельзя никому ничего отобразить.
S>>8. Ничего не делать — проигнорить, но оборвать текущую операцию. DP>+пункт 2 или 4
Тут смотрите как важно. Если изменился пользователь а некая операция продолжила выполняться и завершилась после смены пользователя — то это не ошибка, это штатное поведение. Но при этом нельзя применять результаты данной операции — нужно сгенерить исключение. Но! Пользователю и даже в лог вносить это исключение смысла нет, т.к. ситуация штатная и доп. решения не треубет.
S>>9. Возможно — удалить текущую базу данных ввиду ее повреждения (если база не критична) или отобразить форму невозможности продолжения работы ввиду повреждения базы. DP>ОМГ что???
Да, а что. Если база повреждена — что делать? Если это локальная копия-кеш серверной — удалить и запросить данные заново. А если же база важна — то отобразить как есть, пусть пользователь нанимает специалиста по восстановлению баз данных — ему виднее, может сектор какой на диске полетел.
S>>10. Попытаться устранить проблему автоматически — как-то устаревший формат файла — провести приведение к новому формату. DP>бизнес-логика
Ну оно все бизнес-логика, по сути. То что окошко красное — это не выводит из разряда бизнес-логики.
DP>Итого: 1 пункт про ошибку + 1 про уведомляшку. Остальное про всякое разное стандартное полезное: логгирование, валидация и бизнес-логика
Даже первый пункт — это бизнес-логика. Это все бизнес-логика, но бизнес-логика по обработке исключений.
Здравствуйте, Shmj, Вы писали:
S>Очень важен вариант обработки ошибки вот какой, копирую:
S>
S>Если изменился пользователь а некая операция продолжила выполняться и завершилась после смены пользователя — то это не ошибка, это штатное поведение. Но при этом нельзя применять результаты данной операции — нужно сгенерить исключение. Но! Пользователю и даже в лог вносить это исключение смысла нет, т.к. ситуация штатная и доп. решения не треубет.
S>Т.е. важно уметь оборвать операцию в процессе, но при этом не тревожить пользователя лишними оповещениями, т.к. это штатная ситуация.
Это не "очень важен", это какое-то наркомание. Ложка огурцы банка майонез.
1. Что такое "изменился пользователь"? Во время операции ему (в другом потоке) изменили список ролей/привилегий? Или просто он отключился от "соединения"?
2. Что значит "применять результаты"? Операция — это, как правило, атомарное действие, у которого может быть результат (который просто возвращается, как результат вычисления выражения 2*3), а может быть эффект (который влияет на состояние, как результат выполнения стейтмента x = 2*3). Может быть и то и другое. В итоге, "не применять результаты" — это какой-то оксюморон: результат и так никуда не "применяют". А "не применять эффект" нужно детализировать: то ли разрешать частичное выполнение, то ли нет.
Вот, к примеру, MS SQL Server поддерживает heartbeet даже во время выполнения длинного запроса, который не предусматривает коммуникации с клиентом в процессе.
Ну, там insert into mytable(v) (select sum(values) from VeryLongTableWithoutAppropriateIndices lt where lt.tag % 17 = 3) — результат "1 row(s) updated" приедет только в самом-самом конце.
Но если я в процессе исполнения запроса отключусь (штатно там или аварийно), то сервер это заметит и выполнит rollback transaction.
3. Зачем генерировать исключение, которое вы не собираетесь ни вносить в лог, ни показывать кому-то?
В общем, вам надо аккуратно факторизовать задачу на составляюшие. И тогда решение станет очевидным.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>1. Что такое "изменился пользователь"? Во время операции ему (в другом потоке) изменили список ролей/привилегий? Или просто он отключился от "соединения"?
Это актуально не для того типа приложений, которое вы представили.
В моем случае программа десктопная (или мобильная), вход осуществлен под одним пользователем всегда. Одна база открывается в при открытии программы. При этом пользователь может выйти и зайти под другим никнеймом, в то время как некие операции продолжат выпоняться и запишут результат своей работы (после запроса к серверу) — уже на имя нового пользователя.
Варианты решений?
S>2. Что значит "применять результаты"? Операция — это, как правило, атомарное действие, у которого может быть результат (который просто возвращается, как результат вычисления выражения 2*3), а может быть эффект (который влияет на состояние, как результат выполнения стейтмента x = 2*3). Может быть и то и другое. В итоге, "не применять результаты" — это какой-то оксюморон: результат и так никуда не "применяют". А "не применять эффект" нужно детализировать: то ли разрешать частичное выполнение, то ли нет.
1. Сделал запрос к серверу — получил данные от сервера. Раз.
2. Внес новые данные от сервера в таблицу.
Какая тут может быть атомарность?
S>Вот, к примеру, MS SQL Server поддерживает heartbeet даже во время выполнения длинного запроса, который не предусматривает коммуникации с клиентом в процессе.
Это другая ситуация.
S>3. Зачем генерировать исключение, которое вы не собираетесь ни вносить в лог, ни показывать кому-то?
TG>Вообще, большая часть того, что Вы описали, это не исключительные ситуации, а вполне обычный flow, о котором должен думать ещë аналитик на этапе постановки задачи.
Хорошие у тебя аналитики. У меня обычно на доске нарисуют несколько квадратов со стрелочками и норм.
Жизнь не обязана доставлять удовольствие. Достаточно отсутствия страданий.
Здравствуйте, s_aa, Вы писали:
>>Но в универах так практически никто этого не делает...
D>>Исправил
_>И в реальном бизнесе так сплошь и рядом. Надо быстро и ещё вчера.А когда развернется все, нас тут скорее всего уже не будет.
И поэтому мы сейчас занимаемся стабилизацией так написаных, но важных и глючных фич. И проектируем обработку обшибок вместо тех, которых "уже здесь нет".
Здравствуйте, Shmj, Вы писали:
S>Это актуально не для того типа приложений, которое вы представили.
Это актуально для всех типов приложений. S>В моем случае программа десктопная (или мобильная), вход осуществлен под одним пользователем всегда. Одна база открывается в при открытии программы. При этом пользователь может выйти и зайти под другим никнеймом, в то время как некие операции продолжат выпоняться и запишут результат своей работы (после запроса к серверу) — уже на имя нового пользователя.
Вот это и есть дизайн в стиле безумного шляпника, который создаёт вам проблемы.
S>Варианты решений?
Не делать безумное чаепитие. S>1. Сделал запрос к серверу — получил данные от сервера. Раз. S>2. Внес новые данные от сервера в таблицу.
Пока что вы описали ровно вариант "получить результат запроса". Если пользователь отключился — всё, результат ему не нужен. Зачем вы берётесь записывать этот результат в какие-то таблицы? Пользователь явно выразил своё намерение завершить сессию. Нужно ли извещать сервер о том, что результат не нужен — дело вкуса.
S>Какая тут может быть атомарность?
Очень простая. Но детали сильно зависят от того, что именно делает приложение. С учётом окружающих рассуждений, велики шансы на то, что вы вместо одного из двух типовых паттернов изобрели ещё какое-то безумие.
Поэтому советы по реализации давать трудно.
Остаётся только повториться: вы делаете какую-то дичь, именно поэтому никакие типовые решения вам не подходят. Ни в какой области. Ни в области персистенса, ни в области асинхронного программирования, ни в области обработки ошибок.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Shmj, Вы писали:
S>Говорите конкретно что не так.
Я вам конкретно сказал, что не так. S>Он вышел, но программу не закрыл — старые операции продолжают работать. Механизма отмены нет.
Зачем они "продолжают работать", когда пользователь уже вышел?
S>Весь вопрос в том — как делать отмену. Будете ли вы встраивать в каждый сетевой запрос возможность отмены?
Я же вам вроде бы объяснял, что делать с отменой.
1. Не делать её вообще. Нет никакой разницы, вышел пользователь, или отключился, или у него на клиенте пропало питание. Действие на стороне сервера дорабатывает до конца.
2. Делать отмену на основе транзакционности. См. пример с MS SQL Server.
S>Атомарность может быть при записи в базу. А когда внешний вызов — атомарности быть не может, разве что внешний сервис это предусмотрел — но сразу проблема двух генералов, которая неразрешима в принципе.
Поэтому придумали REST.
S>Так напишите как вы решите задачу:
S>1. Пользователь сделал запрос к серверу от имени Вася. S>2. Пока идет запрос — пользователь Вася вышел и зашел под пользователем Петя. Программу не останавливали. S>3. Пришел ответ запрос, но теперь текущий пользователь — Петя. S>4. ?
Нет такой задачи. Вы её себе нафантазировали, и теперь огребаете.
Упростим ваш сложный сценарий%
1. Пользователь сделал запрос к серверу от имени Вася.
2. Пока идёт запрос — пользователь Вася вышел
Или так:
1. Пользователь сделал запрос к серверу от имени Вася.
2. Пока идёт запрос — пользователь Вася остановил программу
Или так:
1. Пользователь сделал запрос к серверу от имени Вася.
2. Пока идёт запрос — операционная система на клиентской машине аварийно завершила программу
Или так:
1. Пользователь сделал запрос к серверу от имени Вася.
2. Пока идёт запрос — клиентская машина аварийно завершилась (села батарея, отключилась сеть, и т.п.)
Внезапно оказывается, что если научиться обрабатывать одну из этих ситуаций, то автоматически получится ответ на все эти ситуации, и, заодно, на все более сложные сценарии вроде придуманного вами выше.
И способ — очень простой:
1. Пишем в локальную базу "мы собираемся сделать к серверу вот такой запрос" (атомарно)
2. Делаем запрос
3. Получив ответ на запрос, пишем в базу "на запрос получен вот такой ответ" (атомарно).
0. При старте системы, поднимаем из локальной базы список всех запросов, которые прошли через п.1 и не прошли через п.3. Повторяем для всех их них п.2 и 3.
Всё понятно?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Shmj, Вы писали:
S>И как он решит задачу, которая не разрешима даже в теории?
Очень просто — вероятностным образом.
S>>0. При старте системы, поднимаем из локальной базы список всех запросов, которые прошли через п.1 и не прошли через п.3. Повторяем для всех их них п.2 и 3. S>1. Тебе нужно проверить что текущая открытая база (а это десктопное или моб. приложение) — та же самая, того же пользователя. Что если пользователь другой?
У каждого пользователя — своя база. Например. Или нет — зависит от архитектуры.
Например, если бы мы велосипедили клиента к RSDN, то вполне можно было бы использовать ровно одну базу. Потому что состояние локальной реплики никак не зависит от того, под каким пользователем выполняется репликация.
Ну, разве что админские форумы видны только админам; удалять ли их во время репликации под "обычным" аккаунтом — дело вкуса заказчика.
А если бы мы велосипедили, к примеру, почтовый клиент, то для каждого аккаунта создавали бы отдельную базу. Возможность совместного показа писем из нескольких баз была бы решением продакт менеджера (например, в мобильном Outlook она есть, в десктопном — нету).
S>2. Результат запроса нужно не только сохранить в базе, но и применить на форме.
Какой ещё форме? Пользователь вышел из приложения, всё, никаких форм нету.
S>Пользователь нажал на кнопку — делаем запрос к серверу, обновляем таблицу, отображаем на форме. Если пользователь изменился (но форма все так же доступна через IoC глобально) — то что?
То увольняем того, кто так спроектировал. Раз уж он не поддаётся обучению. Либо форма была открыта в контексте пользователя, и при логауте она обязана закрыться. Либо форма открыта в "глобальном" контексте, и тогда её всё равно, кто там пользователь.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>У каждого пользователя — своя база. Например. Или нет — зависит от архитектуры.
Без разницы — все-равно нужно проверить изменилась база или нет. Или изменился ли пользователь. Отож.
S>>Пользователь нажал на кнопку — делаем запрос к серверу, обновляем таблицу, отображаем на форме. Если пользователь изменился (но форма все так же доступна через IoC глобально) — то что? S>То увольняем того, кто так спроектировал. Раз уж он не поддаётся обучению. Либо форма была открыта в контексте пользователя, и при логауте она обязана закрыться. Либо форма открыта в "глобальном" контексте, и тогда её всё равно, кто там пользователь.
Вы представляете себе WinForms. А есть же другие архитектуры — как flutter_bloc. Блок и его состояние хранятся отдельно — форму закрыли, а блок глобально зареган.
Но дело даже не в этом. Даже в том же WinForms — вы можете сделать глобальное событие, которое оповестить сразу N открытых форм. Так вот — прежде чем оповещать — нужно проверить что пользователь тот же самый.
Боле того — запрос к серверу может быть не один а много — так вот, после первого мы уже можем знать что пользователь изменился и далее нет смысла делать запросы. Как оборвать процесс?
Здравствуйте, Shmj, Вы писали:
S>Без разницы — все-равно нужно проверить изменилась база или нет. Или изменился ли пользователь. Отож.
Не надо ничего проверять. Постарайтесь воздержаться от веществ. Хотя бы временно.
S>Вы представляете себе WinForms.
Нет, я представляю собой здравый смысл.
S>А есть же другие архитектуры — как flutter_bloc. Блок и его состояние хранятся отдельно — форму закрыли, а блок глобально зареган.
Это не flutter виноват в том, что у вас в голове каша. Форму закрыли => нет и вопроса о том, как обновить её состояние после окончания асинхронного запроса.
S>Но дело даже не в этом. Даже в том же WinForms — вы можете сделать глобальное событие, которое оповестить сразу N открытых форм. Так вот — прежде чем оповещать — нужно проверить что пользователь тот же самый.
Что такое "оповещать"? Зачем это вообще делать?
S>Боле того — запрос к серверу может быть не один а много
Вот именно. S>- так вот, после первого мы уже можем знать что пользователь изменился и далее нет смысла делать запросы. Как оборвать процесс?
Перестаньте мыслить категориями "пользователь изменился". Забудьте об этом. Вы же видите, что
а) в вашей парадигме возникают проблемы
б) ни у кого другого таких проблем не возникает
Посмотрите на то, как сделано примерно 100% софта.
1. Как правило, нет никакой локальной базы. Нет базы — нет проблем. Банковские приложения, госуслуги, авиасейлз, покупка билетов в театр и прочее — прекрасно живут без локальных баз и фоновых запросов
2. Если есть локальная база, то, как правило, она является либо репликой фрагмента глобальной базы, либо используется для детерминистического управления состоянием. В обоих случаях всё работает вполне простым и предсказуемым образом.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Shmj, Вы писали:
S>В современных приложениях ты обновляешь не форму а состояние. При этом может сразу несколько форм обновиться.
Это никак не связано с клиньями у вас в голове.
S>Чтобы все было интерактивно — событие произошло — все формы, которые связаны с этим событием — мгновенно под него подстроились.
Прекрасно. Как событие, так и формы существуют только в контексте "пользовательской сессии". Если пользователь отключился — всё, нет ни форм, ни оповещений от "предыдущего" пользователя.
Пока вы этого не поймёте, будете страдать. S>Забывайте дедовские технологии, когда событие было привязано к одной форме.
"Дедовские технологии". Юноша, я ещё в конце 90х участвовал в разработке системы, где все открытые формы автоматически отображали произошедшие изменения.
И не только в ответ на запросы "текущего пользователя", а и от других пользователей системы. Вряд ли вы сможете чем-то меня удивить.
S>Возникают — у многих. Но многим пофиг — нет стройной идеологии.
Есть идеология. Проблем нет.
S>Либо решают как вы — что не может быть удобства в виде интерактивного обновления множества форм.
Нет.
S>Вы в каком году живете? Везде даже у каждого сайта есть локальная база на сегодня.
Что за бред вы пишете? Нет никакой локальной базы у сайта. Откройте свой телефон — там у 90% приложений нет никакой "локальной базы". Это можно легко проверить, отключив сеть, и убедившись в том, что кроме пустого экрана приложение ничего не покажет.
S>>2. Если есть локальная база, то, как правило, она является либо репликой фрагмента глобальной базы, либо используется для детерминистического управления состоянием. В обоих случаях всё работает вполне простым и предсказуемым образом.
S>Ну вот вам и предсказуемым — пользователь изменился и привет. Просто обычно об этом не думают, т.к. проблема возникает редко и тестеры особо даже не тестируют.
Да кто вам такой бред сказал? Конечно же тестируют. Просто никто не делает приложения так, как вы — где "база" независима от "пользователя", и от обоих независимы "оповещения".
Попробуйте, скажем, сменить пользователя в приложении Альфа-банка. И посмотрите, действительно ли придёт оповещение об исполнении перевода от "предыдущего" пользователя, и смешаются ли балансы счетов Васи и Пети.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Shmj, Вы писали:
S>Задумался об идеологически правильной обработке ошибок (исключительных ситуаций) в приложениях для обычных пользователей.
По мне так подход с тупым показыванием "что-то пошло не так" с показыванием кода для саппорта и кнопки перезапуска это нормальный вариант, не надо ничего усложнять.
В смысле, приложение должно ошибку внутри во всех подробностях записать для разбора полетов, а для пользователя этого достаточно.
Потому как если пользователь что-то может сделать с ошибкой, то это и не ошибка вовсе, а нормальная рабочая ситуация.
А если пользователь ничего не может сделать, так нечего его и грузить всякой фигней.
Здравствуйте, Shmj, Вы писали:
S>Очень хорошо, здорово. А теперь потрудитесь объяснить что такое "пользовательская сессия" в контексте десктопного приложения. Что за зверь такой? Быть может это что-то типа отдельного процесса на уровне операционной системы?
Нет, зачем? Это просто сессионный токен, который выдан вам сервисом аутентификации. S>Как вы представляете прекращение существования пользовательской сессии? Убить процесс приложения?
Самый простой вариант — да, убить процесс S>Но нет же, при выходе приложение не убивается а продолжает работать — просто переходит на страницу входа. Тогда что же?
Тогда закрыть все формы и освободить связанные с ними структуры данных, в которых используется сессионный токен.
S>Вы когда-нибудь реально меняли? У вас есть два аккаунта разных? Или просто верите в это?
Конечно менял. Там, если что, есть режим с "демо аккаунтом".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Далее, ок. Обнулили данные. А как быть если уже вызвана асинхронная функция, которая делает несколько запросов к серверу? После каждого запроса вам нужно что? Правильно, проверять актуален ли пользователь и если НЕТ — то что? Херачить запросы далее или?
Как правило в больших приложениях используются собственные объекты HttpRequest (например, в виде обверток над стандартными или в виде "перехватчиков"). При отправке запроса всё равно передается сессионный токен, как уже писал Sinclair, вот в ответе и надо проверить, что токен, который использовался при отправке запроса всё еще равен текущему токену — обрывать ничего не надо, достаточно игнорировать ответ или не делать саму отправку, если у вас внутренняя очередь. Или же сравнить UserID (в зависимости, что надежнее, если токены могут обновляться периодически).
Ключевая идея, что это как правило делается в одном месте прозрачно, а не разбросано по всему клиентскому коду.
Кстати, и даже этого не придется делать скорее всего, т.к. при смене пользователя у тебя уничтожатся все экраны, обнулится весь state (если он был), поэтому асинхронные ответы ничего не смогут обновить, потому что там null условно говоря. Экран и стейт под нового пользователя будет создан заново, ссылки будут отличаться, поэтому как правило (если пишешь каноническое Web-приложение на популярном фреймворке) не надо беспокоиться, что из асинхронной функции у тебя обновится экран или стейт старыми данными.
И про это тоже Sinclair в начале ветки писал.
В целом ваша дискуссия похожа на разговор опытного архитектора с начинающим программистом. Лучше сосредоточиться на том, чтобы подумать, как реализовать то, о чем говорит опытный архитектор, вместо того, чтобы загружать его вопросами кодирования, как написать асинхронный обработчик.
Здравствуйте, Shmj, Вы писали:
S>В конце до него наконец дошла идея, которую он не мог понять — что за исключение такое, которое не нужно обрабатывать. Ему привычнее .Net — у меня то стек технологий огромный и я как бы вижу самую суть. Но для него нужно назвать ключевое слово OperationCanceledException.
Не, ты просто дебил. И от стека технологий это не зависит. Суть он видит... Суть в том, что не ссуть, это единственная суть, которую ты видишь
Здравствуйте, Shmj, Вы писали:
S>Ну вот теперь вы и пришли к пониманию зачем нужно исключение, которое оборвет процесс, но его не нужно ни логировать, ни отображать. В .Net это будет — OperationCanceledException.
Здравствуйте, Marty, Вы писали:
S>>Ну вот теперь вы и пришли к пониманию зачем нужно исключение, которое оборвет процесс, но его не нужно ни логировать, ни отображать. В .Net это будет — OperationCanceledException. M>Э-што? Это Sinclair пришел к пониманию?
Понимаю вашу склонность приклоняться пред авторитетами — но истина в этом не нуждается. В данном случае я оказался прав и спустя несколько сообщений Sinclair это понял, теперь молчит.
Здравствуйте, Shmj, Вы писали:
S>>>Ну вот теперь вы и пришли к пониманию зачем нужно исключение, которое оборвет процесс, но его не нужно ни логировать, ни отображать. В .Net это будет — OperationCanceledException. M>>Э-што? Это Sinclair пришел к пониманию?
S>Понимаю вашу склонность приклоняться пред авторитетами — но истина в этом не нуждается. В данном случае я оказался прав и спустя несколько сообщений Sinclair это понял, теперь молчит.
Он молчит, потому что понял, что твою тупость не пробить ничем
Здравствуйте, Shmj, Вы писали:
S>Ты сейчас действуешь по примативному инстинкту — поддержка соц. иерархии. Типа если ты шестеришь перед авторитетом — то якобы можешь стать бета — чистый примативизм.
Ой, я перед Sinclair что ли шестерю? Ты идиот, или просто прикидываешься?
Sinclair тебе всё по полочкам разложил, разжевал, положил в рот. Я ему вообще удивляюсь в данном случае, так терпеливо разжевывать для тебя базовые понятия. Но он вроде преподаёт, у таких есть уже практика общения с неучами
S>Если хочешь действовать не как хомо а как сапиенс — то:
S>1. Объясни суть спора, с чем был не согласен Sinclair.
Видишь ли, если даже у Sinclair не получилось донести до тебя, что ты хернёй маешься, то у меня точно не получится
S>2. Опиши к какому выводу пришли и какое к этому отношение имеет OperationCanceledException.
S>Выбор за тобой — либо быть хомо либо сапиенсом.
А, ты типа вжика, в белой польте стоишь красивый...
Здравствуйте, Marty, Вы писали:
S>>1. Объясни суть спора, с чем был не согласен Sinclair.
M>Видишь ли, если даже у Sinclair не получилось донести до тебя, что ты хернёй маешься, то у меня точно не получится
Ты опять переходишь на свой конек — на личности. Давай технический ответ — о чем был спор технически?
Это вообще не досягаемо для тебя — а то что ты в соц. иерархию примативную умеешь — это мы видели, но это не несет смысла.
Здравствуйте, Shmj, Вы писали:
M>>Видишь ли, если даже у Sinclair не получилось донести до тебя, что ты хернёй маешься, то у меня точно не получится
S>Ты опять переходишь на свой конек — на личности. Давай технический ответ — о чем был спор технически?
Конек или нет — Синклер тебе донёс предельно ясно, всё разжевал, в рот положил
S>Это вообще не досягаемо для тебя — а то что ты в соц. иерархию примативную умеешь — это мы видели, но это не несет смысла.
Мне пох на твою иерархию, а то, что ты непробиваемый дилетант — это ты доказал многократно
Здравствуйте, Marty, Вы писали:
S>>Ты опять переходишь на свой конек — на личности. Давай технический ответ — о чем был спор технически? M>Конек или нет — Синклер тебе донёс предельно ясно, всё разжевал, в рот положил
Ты технически можешь сказать в чем вопрос был — с чем он был не согласен?
Здравствуйте, Shmj, Вы писали:
M>>Ты хочешь, чтобы я повторил то, что до тебя Синклер пытался донести?
S>Нет, ты скажи с чем Синклер конкретно был не согласен. В чем вопрос вообще был? Далее — какое к этому вопросу имеет отношение OperationCanceledException.
S>Попробуй напрячь мозги, перейти из категории гомо в категорию сапиенсов. Но не уверен что сможешь.
Тебе нельзя ничего доказать, когда ты рогом упёрся, да и нет у меня такой нужды. Хочешь быть дураком — будь им, мешать не буду
тоже вот, пожалуйста, ошибочка закралась ))
