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

[belugin]

В дотнете tryxxx


✔️ CONSIDER the Try-Parse Pattern for members that might throw exceptions in common scenarios to avoid performance problems related to exceptions.

✔️ DO use the prefix "Try" and Boolean return type for methods implementing this pattern.

✔️ DO provide an exception-throwing member for each member using the Try-Parse Pattern.

[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

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

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

[mazzy]

Цитата:

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

В дотнете tryxxx

Угу, угу!

это тот же самый случай. Только с другого конца.
Спасибо!

Жаль, что для x++ бесполезен из-за "особенностей" обработки try/catch в транзакциях.

=============
причем такие соглашения не дают абсолютно никаких гарантий.
tryxxx не гарантирует, что метод не бросит исключений (что все исключения обрабатываются)
*noThrow тоже не гарантирует, что метод не бросит исключений
*OrThrow тоже ничего не гарантирует.

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

Что дает читающему абсолютно понятный "контракт".

собственно поэтому в вопросе явно указан [CodeStyle]
и задан вопрос о ваших предпочтениях. а не о том, "как правильно".

[belugin]

Цитата:

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

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

Надо только переписать все стандартные методы, выкидывающие исключения, чтобы они заканчивались на OrThrow.

strFmtOrThrow(getFormatStringFromSetupTableOrThrow(), transaction.calculateTaxAmountOrThrow());

А то будет непонятно в типичном случае.

С моей точки зрения OrThrow больше, так что можно принять его по умолчанию и как-то выделять методы которые, наоброт, не выкидывают исключения.

[mazzy]

Цитата:

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

Надо только переписать все стандартные методы, выкидывающие исключения, чтобы они заканчивались на OrThrow.

Зачем?!
Вот ведь радикальный фундаменталист...

Цитата:

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

strFmtOrThrow(getFormatStringFromSetupTableOrThrow(), transaction.calculateTaxAmountOrThrow());

А то будет непонятно в типичном случае.

хм... надо подумать. спасибо.

Цитата:

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

С моей точки зрения OrThrow больше, так что можно принять его по умолчанию и как-то выделять методы которые, наоброт, не выкидывают исключения.

а как назвать второй метод?
(возвращаясь к опросу)

[belugin]

Цитата:

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

а как назвать второй метод?
(возвращаясь к опросу)

Позаимствовать из любой близкой экосистемы. Так как из X++ можно вызвать .NET я бы взял Try

[mazzy]

подумал...

Цитата:

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

strFmtOrThrow(getFormatStringFromSetupTableOrThrow(), transaction.calculateTaxAmountOrThrow());

думаю, что здесь подход такой же как и к другим длинным именам в C# и Java
в этих платформах рекомендуется делать настолько длинные имена насколько нужно, чтобы точно донести до читающего назначение метода

сравни

strFmtOrThrow(
    getFormatStringFromSetupTableOrThrow(),
    transaction.calculateTaxAmountOrThrow()
);

и

[belugin]

Цитата:

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

думаю, что здесь подход такой же как и к другим длинным именам в C# и Java
в этих платформах рекомендуется делать настолько длинные имена насколько нужно, чтобы точно донести до читающего назначение метода

Если есть reasonable default, то префикс не нужен, чтобы точно донести...