[CodeStyle] методы *noThrow vs *OrThrow vs optional parameter?

[mazzy]

Цитата:

Сообщение от Владимир Максимов

Пример с validateWrite + Write явно надуманный.

Да ну?!
т.е. runbase с эго validate и run - "это другое"

Цитата:

Сообщение от Владимир Максимов

Поскольку в данной теме речь идет именно о создании методов, то и получим дублирование кода

ну... блин... тут явная проблема с логикой.
создание методов вовсе НЕ приводит к дублированию кода.

Цитата:

Сообщение от Владимир Максимов

Это просто счастье, если параметр добавляют. Обычно именно тупо дубликат делают

это проблема конкретной команды и ее конкретного team-лидера.
это НЕ проблема самого CodeStyle.

Насчет параметра.
Правильно говоришь - скорее всего параметров будет много.
вызовов метода с параметрами будет много.
т.е. вот таких конструкций будет дофига:

myObj.myMethod(voucher, inventLocationId, true, inventColorId, false, params);

и как понять этот метод выкинет исключение или нет?
и как понять допустимо ли здесь игнрорировать результат?

поэтому код будет усеян уродливыми конструкциями вида

if( myObj.myMethod(voucher, inventLocationId, true, inventColorId, false, params) )
{
    throw Error::Error
}

а можно было бы одной строкой

myObj.myMethodOrThrow(voucher, inventLocationId, true, inventColorId, params);

Цитата:

Сообщение от Владимир Максимов

Сама постановка вопроса не корректная.

какая постановка?
этого вопроса "Какой вариант вы бы предпочли? И почему?"?
как может быть такая постановка некорректной?

Цитата:

Сообщение от Владимир Максимов

Как правило, подобные методы редко продумываются на этапе создания архитектуры проекта. Они возникают "естественным путем" по мере возникновения в них необходимости. Соответственно и варианты реализации также возникают "по месту". Вот что в данном случае покажется более уместным, то и делают

генезис понятен. согласен, что именно так и происходит.
но это не повод не задавать вопросы
и это не повод не выполнять рефакторинг.
не так ли?

[Владимир Максимов]

Цитата:

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

Да ну?!
т.е. runbase с эго validate и run - "это другое"

Да. Логика другая. Это же не методы ValidateAndRun() и ValidateAndRunNoThrow(). В терминах исходного вопроса тут уместен был бы ValidateNoThrow()

Цитата:

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

ну... блин... тут явная проблема с логикой.
создание методов вовсе НЕ приводит к дублированию кода.

Не приводит, если речь идет о рефакторинге или исходном проектировании архитектуры. При создании методов "естественным путем" - будут дубли

Цитата:

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

это проблема конкретной команды и ее конкретного team-лидера.
это НЕ проблема самого CodeStyle.

Да. Но

1. Рассматриваемый здесь CodeStyle - не стандарт. Собственная разработка
2. При создании методов "естественным путем" требуется рефакторинг, который, в свою очередь, требует времени и сил. Вот сильно сомневаюсь, что с этим станут заморачиваться

Т.е. это все-таки проблемы той команды, которая этот самый CodeStyle будет поддерживать...

Цитата:

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

Правильно говоришь - скорее всего параметров будет много.
(...)
и как понять этот метод выкинет исключение или нет?
и как понять допустимо ли здесь игнрорировать результат?
(...)
поэтому код будет усеян уродливыми конструкциями вида
(...)
а можно было бы одной строкой

Это рассуждения из цикла "сферического коня в вакууме". Реально-то все не так происходит. Как правило, задача разовая.

А вот если задача оказалась не разовая, а часто повторяется, вот в этом случае уже повод задуматься о рефакторинге и каком-то более удобном способе вызова

Цитата:

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

какая постановка?
этого вопроса "Какой вариант вы бы предпочли? И почему?"?
как может быть такая постановка некорректной?

Когда фразу вырывают из контекста, то и получаем не корректную постановку. Я отвечал по контексту дискуссии. Если же вернуться к исходному вопросу, то

Цитата:

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

пример в ax2009 - InventMovement::construct + InventMovement::constructNoThrow
пример в ax2012 - PcGlobalTableConstraintCellEditor::validateIntegerValue + PcGlobalTableConstraintCellEditor::validateIntegerValueNoThrow

Вот это удачный пример решения и именно на этом уровне я бы и остановился.

Т.е. в исходной постановке задачи в данном теме - это метод ValidateWrite() скопировать в метод ValidateWriteNoThrow(), а в самом ValidateWrite() вывести исключение, если проверка с ошибкой

Не надо "копать глубже" и делать ValidateAndWriteNoThrow() - это уже явно лишнее и избыточное решение

Цитата:

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

генезис понятен. согласен, что именно так и происходит.
но это не повод не задавать вопросы
и это не повод не выполнять рефакторинг.
не так ли?

В теории. На практике возможны варианты. И вот не знаю, к счастью или к сожалению. Нет однозначного ответа