vitus_wagner: My photo 2005 (Default)
vitus_wagner ([personal profile] vitus_wagner) wrote2017-03-15 09:37 am

Semantic locality

http://esr.ibiblio.org/?p=7421

Раймонд умный пост написал по поводу концепций, которые лежат под Unix way. Я эту мысль про семантическую локальность три дня думать буду.

[personal profile] inkelyad 2017-03-18 12:08 pm (UTC)(link)
Имеется в виду, что foo[] и может быть той самой валидацией.
Из логики "индекса в массиве не нашлось, значит, пользователь неправильное значение ввел. Ловим исключение и по нему ругаемся."
А тут внезапно индекс не нашелся где-то глубже по вызовам и поэтому все сломалось.
livelight: (Default)

[personal profile] livelight 2017-03-18 12:15 pm (UTC)(link)
По возрастающей степени дебилизма способы валидации такие:

1. Проверяем индекс ("индекса в массиве не нашлось, значит, пользователь неправильное значение ввел"), и если он плохой - внятно ругаемся
2. "Ловим исключение и по нему ругаемся" -- опять же внятно.
3. Прокидываем исключение выше, там пишут 500 Internal Server Error
4. Показываем пользователю кишки системы, а также кровь, распидарасило и стектрейс

[personal profile] inkelyad 2017-03-18 12:26 pm (UTC)(link)
2. "Ловим исключение и по нему ругаемся" -- опять же внятно.
try
... = foo[bar()]
catch IndexOutOfBound
ShowMessage("У вас нет такого номера счета")

Мы вот решили поймать исключение при индексировании foo и внятно выругаться.
Семантика у foo такая, что если в нем чего-то нет, то пользователь не тот счет ввел
Вот только оказалось, что исключение прилетело не от нашего индексирования, а из глубин bar.
И все - при какой-то совершенно посторонней ошибке пользователю показывается "У вас нет такого счета".
А потом еще интефейс усовершенствовали, чтобы вводить ничего не надо, а надо выбрать из списка, но проверку оставили.
livelight: (Default)

[personal profile] livelight 2017-03-18 01:13 pm (UTC)(link)
То есть, предлагаете присвоить такому способу третий уровень идиотизма, а не второй? :)

[personal profile] inkelyad 2017-03-18 01:36 pm (UTC)(link)
А вот бы знать.
Это демонстрация того, как я понял утверждения хозяина журнала о потере контекста - что одно и то же исключение, которое бросилось тут и или там, нужно как-то различать , но это немного затруднительно.
livelight: (Default)

[personal profile] livelight 2017-03-18 01:46 pm (UTC)(link)
Пользователю нужно сообщение с бизнес-смыслом.
Исключение OutOfBounds не имеет никакого бизнес-смысла само по себе, откуда бы оно ни вылетело. Оно может обрести такой смысл только после анализа инцидента разработчиками.
Однако, во многих случаях и глубокоуровневый код имеет возможность выкинуть исключение с бизнес-смыслом. Хотя бы ValidationFailedOutOfBoundsException extends ArrayIndexOutOfBoundsException - кому надо, может его поймать особым образом с учётом его бизнес-смысла, а кто не может - тот обработает его как техническое ArrayIndexOutOfBoundsException. Контекстом в данном случае будет точный подкласс и дополнительные его поля.
livelight: (Default)

[personal profile] livelight 2017-03-18 06:32 pm (UTC)(link)
Идеальным разработчикам в вакууме вполне по силам проанализировать все возможные исключительные ситуации (включая поломки внешних и внутренних систем, протёкшие абстракции того уровня, на котором эти программисты как раз работают и корявые введённые данные) и краевые случаи во всех возможных комбинациях и предусмотреть внятную диагностику для пользователя и хорошие процедуры фейл-бэка (например, чтобы банкомат, прежде чем сказать "ой, всё", постарался отдать пользователю его карточку). В реальной же жизни у них случаются баги, которые требуют анализа уже постфактум - для чего уже нужны логи, стек-трейсы и т.д.
Edited 2017-03-18 18:42 (UTC)
yurikhan: (Default)

[personal profile] yurikhan 2017-03-19 04:25 pm (UTC)(link)
Идеальный банкомат должен говорить, сколько у него осталось каких денег, не пользователю, а банку в заббикс. Чтобы по алёрту прибежал админ и поменял оранжевый (сине-зелёный, фиолетовый, коричневый) картридж.