Задумался об идеологически правильной обработке ошибок (исключительных ситуаций) в приложениях для обычных пользователей.
Конечный итог ошибки может быть таким:
1. Подсветить поле с неверно введенными данными. Самый мягкий случай, когда ошибка ввода данных. Нужно сделать без перехода и диалогов.
2. Отобразить пользователю диалог модальный, когда ошибка важная и требует чтобы пользователь увидел.
4. Отобразить всплывающее окошко. Когда ошибка не важна, скрывать будет не верно (хотя бы для целей отладки и светлого будущего программы), но и она особо погоды не строит.
5. Перевести пользователя в оффлайн-режим. К примеру, если нет подключения, но программа может работать в оффлайн.
6. Заставить пользователя пройти повторную авторизацию (переадресовать на форму входа). Если данные аутентификации отозваны, устарели и пр. Сюда же относим прочие переадресации на формы для обязательного ввода данных (а может быть и не обязательные).
7. Просто записать данные в лог/удаленный лог.
8. Ничего не делать — проигнорить, но оборвать текущую операцию.
9. Возможно — удалить текущую базу данных ввиду ее повреждения (если база не критична) или отобразить форму невозможности продолжения работы ввиду повреждения базы.
10. Попытаться устранить проблему автоматически — как-то устаревший формат файла — провести приведение к новому формату.
Итого — дофига разных вариантов какие типы реакций могут быть.
Фактически нужно помнить что каждая КАЖДАЯ операция может либо завершиться успешно — либо с ошибкой. Причем нужно правильно отреагировать — выбрать какой из 10 вариантов применить.
Есть типовые проблемы, которые могут возникнуть в любом приложении — но очень редко и маловероятно. К примеру, что если я выйду из RSDN, но форму с сообщением не закрою. Потом войду под другим аккаунтом и отправлю сообщение. Под каким пользователем оно опубликуется — под новым или под старым? А ведь я отвечал на сообщение старого пользователя, там от его имени все. Отож. Вывод:
Каждая операция должна проверять под каким пользователем она была начала и если пользователь в процессе операции изменился — то оборвать работу (или даже откатить изменения).
Благо что все эти проблемы возникают не так часто, можно об этом не думать, иначе архитектура усложняется на порядок.