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

Даже первый пункт — это бизнес-логика. Это все бизнес-логика, но бизнес-логика по обработке исключений.