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 про уведомляшку. Остальное про всякое разное стандартное полезное как-то логгирование, валидация и бизнес-логика

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 про уведомляшку. Остальное про всякое разное стандартное полезное: логгирование, валидация и бизнес-логика