| View Poll Results: Какой вариант вы бы предпочли? И почему? | |||
| 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% |
| Voters: 12. You may not vote on this poll | |||
|
|
Thread Tools |
|
|
#15 |
|
Участник
|
Quote:
Была и другая вводная. Но я переписал на эту. Quote:
О validate (который и в runbase есть) и write/update (который и в runbase есть) ![]() Да-да. оставлены голые методы голого ядра. в которые тем не менее программист может вставить код. Quote:
Originally Posted by Владимир Максимов
Если не рассматривать именно этот пример, а сосредоточится на исходной постановке
Метод возвращает true/false. Если false, то следует ли вызывать исключение вместо возврата false? То тут проблема не столько в разовом (однократном) написании, сколько в сопровождении. Т.е. возможности внесения изменений Например, к указанной постановке задачи еще добавляют, а надо ли в случае false, если это не throw выводить текст сообщения об ошибке? Или, например, делать throw не для всех ошибок, а только для определенных? как появляются эти noThrow-метод (как я это вижу) 1. разработчики пишут обычный метод, который бросает исключение 2. а потом начинают его вызывать из другого кода, где есть своя транзакция. и... 3. опа! вложенные catch обработчики перестают работать. Надо что-то делать! 4. из обычного метода выделяется смысловая часть в NoThrow-метод, которое возвращает какой-то результат. А выбрасывание исключения оставляется в исходном. Давно уже один раз я видел, когда произошло немножко наоборот. Чел заметил, что он всегда бросает исключение. Поэтому он написал OrThrow-метод. В результате получил очень чистый код в вызывающих методах. Мне тогда очень понравилась эта техника. Чел, проявись, пожалуйста. дай наставить тебе лайков. Quote:
если посмотреть на 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++ Quote:
расскажите почему вы решили что будет дублирование? ну, хоть на примере 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? какой стиль лучше на ваш взгляд? особенно для нескольких параметров. ![]() Quote:
поэтому и вопрос - а какие другие причины могут делать тот или иной способ удобнее для читающего? Тю-тю-тю-тю... Стопэ! у меня ничего про "сокращение написания кода" не было. если вы считаете, что было - прошу цитату. с этим никто не спорит. |
|
|
|
«
Previous Thread
|
Next Thread
»
|
|