AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

Результаты опроса: Какой вариант вы бы предпочли? И почему?
validateAndWrite() + validateAndWriteNoThrow() 1 8.33%
validateAndWriteOrThrow() + validateAndWrite() 0 0%
validateAndWrite(boolean noThrow = false) 1 8.33%
validateAndWrite(boolean noThrow = true) 0 0%
validateAndWrite(boolean throwIfError = false) 0 0%
validateAndWrite(boolean throwIfError = true) 2 16.67%
я предложил свой вариант в этой ветке 2 16.67%
затрудняюсь ответить, просто хочу посмотреть результаты опроса 6 50.00%
Голосовавшие: 12. Вы ещё не голосовали в этом опросе

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 30.07.2021, 21:11   #1  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,657 / 1158 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Вообще говоря, пример с validateWrite + Write наглядный, но вводит в заблуждение относительно самой постановки вопроса. Сразу вопрос о транзакциях, разделении проверки и модификации и т.д. и т.п. Если не рассматривать именно этот пример, а сосредоточится на исходной постановке

Метод возвращает true/false. Если false, то следует ли вызывать исключение вместо возврата false?

То тут проблема не столько в разовом (однократном) написании, сколько в сопровождении. Т.е. возможности внесения изменений

Например, к указанной постановке задачи еще добавляют, а надо ли в случае false, если это не throw выводить текст сообщения об ошибке? Или, например, делать throw не для всех ошибок, а только для определенных?

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

Ну, и традиционно, дублирование кода получаем, что крайне не желательно. Впрочем, об этом уже говорили

Т.е. я за один общий метод с параметрами.

Насчет того, что придется смотреть, что этот метод делает и что это за параметры, так это в любом случае придется делать. Даже если это будет в исходной постановке с кучей специализированных методов. По многим причинам

То же самое и по поводу сокращения написания кода. Ну очень сомнительный аргумент. Далеко не факт, что такое сокращение вообще получится. А в общем случае, основное время разработчик тратит вовсе не на первичное написание кода, а на его отладку.
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
Старый 30.07.2021, 23:13   #2  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Вообще говоря, пример с validateWrite + Write наглядный, но вводит в заблуждение относительно самой постановки вопроса.
Угу. Сознательно пошел на упрощение.
Была и другая вводная. Но я переписал на эту.

Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Сразу вопрос о транзакциях, разделении проверки и модификации и т.д. и т.п.
Именно-именно. О транзакциях. И о вложенных транзакциях.
О validate (который и в runbase есть) и write/update (который и в runbase есть)
Да-да. оставлены голые методы голого ядра. в которые тем не менее программист может вставить код.

Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Если не рассматривать именно этот пример, а сосредоточится на исходной постановке

Метод возвращает true/false. Если false, то следует ли вызывать исключение вместо возврата false?

То тут проблема не столько в разовом (однократном) написании, сколько в сопровождении. Т.е. возможности внесения изменений

Например, к указанной постановке задачи еще добавляют, а надо ли в случае false, если это не throw выводить текст сообщения об ошибке? Или, например, делать throw не для всех ошибок, а только для определенных?
угу-угу. именно в эту сторону.

как появляются эти noThrow-метод (как я это вижу)
1. разработчики пишут обычный метод, который бросает исключение
2. а потом начинают его вызывать из другого кода, где есть своя транзакция. и...
3. опа! вложенные catch обработчики перестают работать.
Надо что-то делать!
4. из обычного метода выделяется смысловая часть в NoThrow-метод, которое возвращает какой-то результат. А выбрасывание исключения оставляется в исходном.

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

Мне тогда очень понравилась эта техника. Чел, проявись, пожалуйста. дай наставить тебе лайков.

Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Если у нас один метод с параметром, то просто добавим еще параметры в этот один метод. А если методов много, то во все придется делать такое добавление.
Вот да... получается, что во все... это и коробит.

если посмотреть на
https://en.cppreference.com/w/cpp/la.../noexcept_spec
https://docs.oracle.com/javase/tutor.../throwing.html
то видно, что люди думали над этой задачей. Но не сказать, что пришли к каким-то удовлетворительным решениям.

конкретно эта тема появилась здесь после плотного размышления над статьей
http://eao197.blogspot.com/2021/07/progthoughts-c.html

подумалось о noThrow-методах и о том, а что можно было бы сделать в X++ с его дикими ограничениями.

Опять же Котлин - там можно юзать именованные параметры в вызывающих методах. Что сразу делает читающему сухо и комфортно
https://kotlinlang.ru/docs/reference/functions.html

не говоря уже о контрактах и всевозможнных лямбдах и apply-методах
https://stackoverflow.com/questions/...ions-in-kotlin

ну и нормально работающих try/catch c finnaly...

и эцилопп меня не имеет права бить по ночам
...

ладно... в общем, вопрос что можно сделать в X++

Цитата:
Сообщение от mazzy Посмотреть сообщение
Какой вариант вы бы предпочли? И почему?
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Ну, и традиционно, дублирование кода получаем, что крайне не желательно. Впрочем, об этом уже говорили
ну, раз вы настаиваете,
расскажите почему вы решили что будет дублирование?

ну, хоть на примере noThrow методов в стандартной аксапте

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

если хотите, на примере того, что я выложил публично
https://github.com/mazzy-ax/SysUtil/....xpp#L496-L519

Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Т.е. я за один общий метод с параметрами.
т.е. вы предпочитаете видеть в вызывающем методе подобный код:
X++:
buf.validateAndWrite(false)
ну, ооок...
а вы предпочитете видеть true или false для обозначения с исключением или без?
или стоит создавать специальный enum?
какой стиль лучше на ваш взгляд?

особенно для нескольких параметров.

Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Насчет того, что придется смотреть, что этот метод делает и что это за параметры, так это в любом случае придется делать. Даже если это будет в исходной постановке с кучей специализированных методов. По многим причинам
это да. в X++ да.
поэтому и вопрос - а какие другие причины могут делать тот или иной способ удобнее для читающего?

Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
То же самое и по поводу сокращения написания кода.
Тю-тю-тю-тю... Стопэ!
у меня ничего про "сокращение написания кода" не было.
если вы считаете, что было - прошу цитату.

Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Ну очень сомнительный аргумент. Далеко не факт, что такое сокращение вообще получится. А в общем случае, основное время разработчик тратит вовсе не на первичное написание кода, а на его отладку.
с этим никто не спорит.
__________________
полезное на axForum, github, vk, coub.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
bojensen: Optional filter in SSRS | Musings by Generator Blog bot DAX Blogs 0 08.09.2014 11:11
emeadaxsupport: Manufacturing Execution in AX 2012: Issue with the "Lock employee"-parameter Blog bot DAX Blogs 0 19.09.2013 18:11
emeadaxsupport: "Parameter is missing a value" error running a customized report in Microsoft Dynamics AX 2012 Blog bot DAX Blogs 0 21.11.2012 00:12
mfp: Optional parameters in C# and X++ Blog bot DAX Blogs 0 30.01.2010 00:05
Developer notes: Null value for ADO command parameter Blog bot DAX Blogs 0 03.05.2008 08:16

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 05:52.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.