Вспомогательные классы проверки условий и утверждений

[S.Kuskov]

Цитата:

Сообщение от gl00mie

выводить детализированные, четкие и понятные предупреждения и сообщения об ошибках в ходе проверки пред/постусловий и проч., чтобы и пользователи, и специалисты поддержки понимали, почему код "сломался" и/или не делает то, что ожидается, и не задавали лишних вопросов (сообщения вида "класс вызван с неверными параметрами" без дополнительных пояснений - это ни о чем);

Вот с этим пунктом не совсем согласен (а он на самом деле является ключевым). В смысле не согласен с тем что представленное средство решает эту проблему. Скорее даже наоборот.

Чем принципиально отличается детализированные сообщения от недетализированных? Тем что вместе с ошибкой "класс вызван с неверными параметрами" будет выведена ещё и трасировка стека? Или в сообщении "поле должно быть заполненно" будет полностью расшифрованы названия таблиц и обязательных полей? Нет пользователям не нужны такие детализированные сообщения, пользователям нужны сообщения на естественном языке, на языке бухгалтера, экономиста, кладовщика и т.д и т.п. Вот программистам нужны детализированные сообщения. Так им проще локализовать ошибку.

Ставя на поток процесс обработки ошибок, есть риск совсем обезличить тексты сообщений - получить эфект машинного перевода.Есть конечно такие области системы (базовые классы, таблицы или универсальные обработки), в которых находится общая логика, где уже при всём желании невозможно конкретизировать выполняемую в данный момент задачу. Там такая автоматизация обезличенных проверок очень к стати. Задача же клиентского кода работающего с конкретной задачей пропустить минимум ошибок мимо себя в такие базовые области. Т.е. Нужно стремиться ловить ошибки как можно ближе к месту их возникновения, тогда будет проще описывать их на естественном языке.

[gl00mie]

Цитата:

Сообщение от S.Kuskov

Чем принципиально отличается детализированные сообщения от недетализированных? Тем что вместе с ошибкой "класс вызван с неверными параметрами" будет выведена ещё и трасировка стека? Или в сообщении "поле должно быть заполненно" будет полностью расшифрованы названия таблиц и обязательных полей?

Нет, сообщения будут вполне обычными: поле такое-то должно быть заполнено, поле такое-то НЕ должно быть заполнено, значение поля такого-то должно быть в диапазоне от и до, значение поля должно быть больше/меньше/не равно такому-то значению и т.п. Идея в том, чтобы сделать "говорящими" по возможности все логические выражения, не перегружая при этом код, что в сочетании с грамотным использованием setprefix() подчас просто творит чудеса Без подобных средств модификации зачастую пишутся так, что проверяется с десяток самых разных условий, делается пяток ветвлений в коде, и на выходе пользователь получает лишь скупое "обновление было отменено".

Цитата:

Сообщение от S.Kuskov

пользователям не нужны такие детализированные сообщения, пользователям нужны сообщения на естественном языке, на языке бухгалтера, экономиста, кладовщика и т.д и т.п.

У вас наверняка в Аксапту уже встроен искусственный интеллект? Пользователи могут не подозревать о том, какой сложности функционал отрабатывает в ответ на их действия, именно поэтому в т.ч. им нужны детализированные сообщения об ошибках, в которых передается контекст происходящего и объясняется, какие проверки привели к тем или иным решениям.

Цитата:

Сообщение от S.Kuskov

Вот программистам нужны детализированные сообщения. Так им проще локализовать ошибку.

"Если врач сыт, то и больному легче..." (с) х/ф "Формула любви"

Цитата:

Сообщение от S.Kuskov

Есть конечно такие области системы (базовые классы, таблицы или универсальные обработки), в которых находится общая логика, где уже при всём желании невозможно конкретизировать выполняемую в данный момент задачу.

Да все возможно - setprefix() рулит! Просто нужно контекст передавать в сообщениях об ошибках, тогда они станут намного понятнее и доходчивее.

Цитата:

Сообщение от S.Kuskov

Задача же клиентского кода работающего с конкретной задачей пропустить минимум ошибок мимо себя в такие базовые области. Т.е. Нужно стремиться ловить ошибки как можно ближе к месту их возникновения, тогда будет проще описывать их на естественном языке.

Непонятно, что тут понимается под клиентским кодом. validateField() на таблице - это клиентский код?..

[S.Kuskov]

Цитата:

Сообщение от gl00mie

Идея в том, чтобы сделать "говорящими" по возможности все логические выражения, не перегружая при этом код, что в сочетании с грамотным использованием setprefix() подчас просто творит чудеса Без подобных средств модификации зачастую пишутся так, что проверяется с десяток самых разных условий, делается пяток ветвлений в коде, и на выходе пользователь получает лишь скупое "обновление было отменено".

На самом деле хорошая идея. Главное правильно её применить. Ещё раз спасибо

P.S.: Вы не любите кошек? Да вы просто не умеете их готовить!