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

[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 больше, так что можно принять его по умолчанию и как-то выделять методы которые, наоброт, не выкидывают исключения.

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

[mazzy]

подумал...

Цитата:

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

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

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

сравни

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

и

[belugin]

Цитата:

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

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

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

[belugin]

Цитата:

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

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

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

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

Цитата:

Сообщение от 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

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

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

[AlexSD]

Цитата:

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

Какой вариант вы бы предпочли? И почему?

И так и так. В одном случае так, а в другом по другому. Например, код вызываемый на кнопке для проверки текущей строки или обработка кучи записей в цикле, что бы найти все ошибки во множестве записей.

Это как спросить, "вы будете есть ложкой или вилкой" и не уточнить меню.
Отвечю универсально: буду есть и ложкой, и вилкой, и еще попрошу нож