|
unit-тестирование
|
|||
---|---|---|---|
#18+
На самом деле я не хочу спорить по этой теме. Тут вроде-бы все ясно. Но если ситуация - непредвиденная то надо упасть сразу и не растягивать удовольствие до продакшена. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.09.2020, 15:04 |
|
unit-тестирование
|
|||
---|---|---|---|
#18+
mayton Но если ситуация - непредвиденная то надо упасть сразу и не растягивать удовольствие до продакшена. но null может быть и нормальной ситуацией ... |
|||
:
Нравится:
Не нравится:
|
|||
11.09.2020, 15:20 |
|
unit-тестирование
|
|||
---|---|---|---|
#18+
вадя mayton Но если ситуация - непредвиденная то надо упасть сразу и не растягивать удовольствие до продакшена. но null может быть и нормальной ситуацией Ты думаешь я тут в топике буду биться с тобой до конца? Да ради бога. Возвращаяй null как предвиденную ситуацию. Насколько я понимаю ты - фулл-стекер и работаешь сам на себя? Команды нет? Следовательно нет никаких организационных вопросов с кодом? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.09.2020, 15:59 |
|
unit-тестирование
|
|||
---|---|---|---|
#18+
mayton Ты думаешь я тут в топике буду биться с тобой до конца? Да ради бога. что тогда возвращать если null обозначает отсутствие объекта/данных, и такое отсутствие не ошибка? эксепщен? остановка всего приложения? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.09.2020, 17:25 |
|
unit-тестирование
|
|||
---|---|---|---|
#18+
Он же объяснил что возвращать. В двух вариантах. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.09.2020, 17:31 |
|
unit-тестирование
|
|||
---|---|---|---|
#18+
mayton Я использовал пустое значение NIL или () в языках высокого уровня и это не вызывало проблем. Лисп оставим в покое, а разыменовывать NIL и Паскале нельзя. И в Це, с которого "списывали" Яву и в Це-с-крестами. Система типов и операций в Java и SQL обрела общие черты или мы сейчас за концепции? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.09.2020, 17:40 |
|
unit-тестирование
|
|||
---|---|---|---|
#18+
mayton Он же объяснил что возвращать. В двух вариантах. если по логике дефолтное значение далее может выкинуть ещё какую ошибку? вот сделал - дефолтное - а потом другие будут разбирать - откуда такое значение? в базе нет, в источнике - нет, а значение есть. null видишь - нет, а он есть... в то время когда null однозначно показывает что ничего нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.09.2020, 17:51 |
|
unit-тестирование
|
|||
---|---|---|---|
#18+
Мы щас говорим о том что существуют языки где семантика операций с NULL - безопасна. Санкционирована. Рекомендована. И даже более того. Как вы заметили в List пустой список и NIL синонимы. Они-же являются синонимом логического результата false в булевом контексте. Про БД мы уже говорили. Реляционная алгебра просто не существует без синонима "выколотого элемента множества". Этот термин я не придумал. Это из учебнкиа дискретной математики. Тоесть в этих сферах null/NIL/() это хоршо. Это гуд. В отличие от машинно-ориентированных языков таких как C/C++ , ноль имеющий тип указателя требует особого бережного обхождения. Тут по сути - не вопрос правильно или неправильно. А вопрос культуры. Тоесть оставляем-ли мы после себя наследие в виде небезопасного кода который как Чеховское Ружье стреляет во 2-м акте. Причем стреляет больно и дорого для иммиджа. Или мы на уровне джентльменских соглашений решаем что мы убираем из кода любую потенциальную возможность получить ошибку ценой в миллиард. Я - за джентльменские соглашения. Кстати недавно кто-то постил NASA-вские рекомендации по надежности кода. Там - куда более суровые требования. Требуют гарантированного доказательства завершения любого цикла. Требуют отсутствия в коде рекурсий. И требуют какого-то лимита на уроввни вложения conditions в камках 1 процедуры. Ваш покорный слуга просто предложил подойти к null с точки зрения ентерпрайзных практик. И это я пишу не для Василия. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.09.2020, 17:54 |
|
unit-тестирование
|
|||
---|---|---|---|
#18+
null-ы в функциональные конвейеры не вписываются. И вообще - try-catch это многабукав ... |
|||
:
Нравится:
Не нравится:
|
|||
11.09.2020, 17:54 |
|
unit-тестирование
|
|||
---|---|---|---|
#18+
Basil A. Sidorov забыл ник Если в сигнатуре метода написано Int - значит не должен возвращаться null, это хак системы типов Жить станет проще если принять как данность, что после того как создал обьект- ты должен его за собой и прибрать. Если бы это было продуктивной идеей, то и java бы не возникла. Можно конечно добавить скорости, но вы же не хотите проседания в скорости? Знакомо? Не понимаю упорного сопротивления в признании того что null это абсолютное и бескомпромиссное зло. Наверное на это влияет корявость реализации optional в java, из-за которого приходится писать много boilerplate. Другого объяснения у меня нет ... |
|||
:
Нравится:
Не нравится:
|
|||
11.09.2020, 22:39 |
|
unit-тестирование
|
|||
---|---|---|---|
#18+
вадя забыл ник Поэтому сигнатура метода четко должна указывать что значение возможно не найдено. Optional<Int> ты не будешь это проверять? сигнатура тебе это указала и дальше что? Смотря в каком стиле писать. В императивном, да, много мороки с optional чтобы постоянно извлекать и запаковывают назад, но я все равно за лучшую типобезопасность, даже в императивке. В функциональном стиле все проще - допустим вызываем getEmployee() который возвращает Optional, а потом .map(getDepartment).map(getid).orElse(defaultId). То есть у тебя вся цепочка вычислений происходит в контексте Optional, нет нужды извлекать и переименовывать.. И только на самом верху, в контроллере, ты уже будешь проверять, если optional не содержит ничего - кидаем 404, содержит - возвращаем результат. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.09.2020, 22:49 |
|
unit-тестирование
|
|||
---|---|---|---|
#18+
забыл ник, Можно конечно добавить скорости, но вы же не хотите проседания в скорости? Читать как Можно конечно добавить сборщик мусора, но вы же не хотите проседания в скорости? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.09.2020, 22:51 |
|
unit-тестирование
|
|||
---|---|---|---|
#18+
вадя так почему не проще проверить на null, вместо дефолтного значения? потому что забудешь. любой, даже автор кода, рано или поздно где-то что-то забудет. в лучшем случае ты будешь использовать аннотацию @Nullable, прокидывая ее вверх по иерархии вызовов, чтоб тебе хоть IDE возможные места NPE подсветила, в худшем и этого не будет. в лучшем случае ты нарвешься сразу на NPЕ или через неделю, в худшем оно всплывет спустя два года. Так интересно совпало, я сегодня хапнул NPE в классе, который с 2016 года не менялся :) ... |
|||
:
Нравится:
Не нравится:
|
|||
11.09.2020, 23:44 |
|
unit-тестирование
|
|||
---|---|---|---|
#18+
А откуда в топике появилась мысль о "проседании скорости"? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.09.2020, 07:53 |
|
unit-тестирование
|
|||
---|---|---|---|
#18+
забыл ник у тебя вся цепочка вычислений происходит в контексте Optional, нет нужды извлекать и переименовывать.. И только на самом верху, в контроллере, ты уже будешь проверять, если optional не содержит ничего - кидаем 404, содержит - возвращаем результат. Во-вторых, судя по всему в жаве никто тупняк с женериками убирать не собирается, поэтому метод хоть и может возвращать Optional<?>, а вот чтобы метод мог принимать Optional<?> в качестве аргумента ну уж очень сильно не рекомендуется. Вот без решения по крайней мере этих двух проблем говорить о повсеместном использовании Optional<?> в жаве не приходится. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.09.2020, 08:34 |
|
unit-тестирование
|
|||
---|---|---|---|
#18+
забыл ник null это абсолютное и бескомпромиссное зло ... |
|||
:
Нравится:
Не нравится:
|
|||
12.09.2020, 10:10 |
|
unit-тестирование
|
|||
---|---|---|---|
#18+
В топике NPE (не в главном а в том который спонтанно возник) есть две линии спора. Одна линия - предпринять действия для уменьшения возможности получения этого дефекта и вторая линия - не делать ничего. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.09.2020, 10:38 |
|
unit-тестирование
|
|||
---|---|---|---|
#18+
Basil A. Sidorov забыл ник null это абсолютное и бескомпромиссное зло Ты так удивляешься, как будто вышеперечисленное есть норма. Переполнение стека, разыменование указателя на несуществующую область памяти, утечка файловых указателей тоже когда-то казались нормой, но к счастью инструменты а главное ремесло программирования не стоит на месте. И только ретрограды злобно кричат вслед и машут кулачками. Священный грааль программирования как раз и состоит в том что все ошибки должны быть автоматически отловлены еще на этапе компиляции. К сожалению из-за halt-problem это невозможно, но это не повод не пытаться приблизиться к идеалу. ЕДинственные ошибки, на которых должен концентрироваться программист(не системный) - это ошибки в бизнес-логике, да и те можно сводить к минимуму с помощью системы типов ... |
|||
:
Нравится:
Не нравится:
|
|||
12.09.2020, 17:30 |
|
unit-тестирование
|
|||
---|---|---|---|
#18+
Андрей Панфилов Больше смахивает на результат работы кода, который толком никому не нужен, а не на какую-то киллер-фичу. Поясни, не понял что к чему. Андрей Панфилов Вот, к примеру, у меня есть желание иметь возможность хоть какой-нибудь отладки, поэтому я хочу в условных переходах понатыкать логирования, вот куда мне это логирование вставлять если "вся цепочка вычислений происходит в контексте Optional"? Отладки чего? Что касается Java, я с тобой не спорю. И в принципе понимаю сопротивление против Optional, потому что его выгода не очевидна. Но мы вроде как говорим о проблеме null в более широком смысле? На примере скалы - если тебя нтересует присутствие\отсутствие значения, независимо от причины - тогда Optional и логирование бессмысленно. Если нужно знать что конкретно и где свалилось - Either<Error, Result> - в каждой ветви ты можешь либо пробросить результат дальше либо закончить вычисление с Error("Причина"). Я работаю на скала+спарк, так вот - мне не только логгирование но и дебаггер то особо не нужен, включаю раз в три дня Андрей Панфилов Во-вторых, судя по всему в жаве никто тупняк с женериками убирать не собирается, поэтому метод хоть и может возвращать Optional<?>, а вот чтобы метод мог принимать Optional<?> в качестве аргумента ну уж очень сильно не рекомендуется. Согласен, так а зачем передавать optional в метод? Твои бизнес функции должны быть типа A -> B, а вот вызывать их или нет будет решать контекст Optional, что как раз и является киллер-фичей. Андрей Панфилов Вот без решения по крайней мере этих двух проблем говорить о повсеместном использовании Optional<?> в жаве не приходится. Ну в жаве да, но ты в целом солгасен с утверждением что null это зло? И если бы был адекватный инструментарий то им и надо было бы пользоваться? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.09.2020, 17:42 |
|
unit-тестирование
|
|||
---|---|---|---|
#18+
забыл ник Поясни, не понял что к чему. Код: java 1.
мне совершенно не нравится тем, что его невозможно сопровождать с точки зрения поддержки, т.е. прилетает запрос от пользователя в духе: "я тут нажимаю кнопку, а мне вместо ожидаемого результата приходит что-то не то, что я ожидаю", наиболее приемлемым вариантом был бы такой: поддержка включает дебаг, отжимает кнопку и видит в логе, что Петя не привязан к отделу, или что у отдела нет руководителя, т.е. в таком случае сопровождаемость решения зависит от того есть логирование в условных переходах или нет (ну т.е. достаточно только код писать нормально), а в случае цепочки map условные переходы есть, а логирование вставлять некуда, т.е. от null вроде как избавились, а решение при этом получилось совершенно несопровождаемым, потому что нужно на любой чих лезть в код и угадывать что там там не так Андрей Панфилов На примере скалы - если тебя нтересует присутствие\отсутствие значения, независимо от причины - тогда Optional и логирование бессмысленно. Если нужно знать что конкретно и где свалилось - Either<Error, Result> - в каждой ветви ты можешь либо пробросить результат дальше либо закончить вычисление с Error("Причина"). Я работаю на скала+спарк, так вот - мне не только логгирование но и дебаггер то особо не нужен, включаю раз в три дня Андрей Панфилов Согласен, так а зачем передавать optional в метод? Твои бизнес функции должны быть типа A -> B, а вот вызывать их или нет будет решать контекст Optional, что как раз и является киллер-фичей. Андрей Панфилов Ну в жаве да, но ты в целом солгасен с утверждением что null это зло? - информация об отсутствии данных, это тоже данные, вадя тут совершенно прав, если бы был вменяемый механизм разграничения, можно было бы по крайней мере задуматься об использовании, а бежать и переделывать все на Optional<?> - толку мало, это как сейчас некоторые индивидуумы начали резво избавляться от интерфейсов и оперировать исключительно интерфейсами из java.util.function, в итоге с кодом ничего толком сделать нельзя кроме как удалить и написать правильно - в жаве слишком мало налов, нужно было развивать первоначальные идеи Кодда и делать несколько видов ... |
|||
:
Нравится:
Не нравится:
|
|||
12.09.2020, 18:34 |
|
unit-тестирование
|
|||
---|---|---|---|
#18+
Андрей Панфилов забыл ник Поясни, не понял что к чему. Код: java 1.
мне совершенно не нравится тем, что его невозможно сопровождать с точки зрения поддержки, т.е. прилетает запрос от пользователя в духе: "я тут нажимаю кнопку, а мне вместо ожидаемого результата приходит что-то не то, что я ожидаю", наиболее приемлемым вариантом был бы такой: поддержка включает дебаг, отжимает кнопку и видит в логе, что Петя не привязан к отделу, или что у отдела нет руководителя, т.е. в таком случае сопровождаемость решения зависит от того есть логирование в условных переходах или нет (ну т.е. достаточно только код писать нормально), а в случае цепочки map условные переходы есть, а логирование вставлять некуда, т.е. от null вроде как избавились, а решение при этом получилось совершенно несопровождаемым, потому что нужно на любой чих лезть в код и угадывать что там там не так Если на входе теоретически может быть мусор, то должен быть класс-валидатор, который проверит всё в самом начале и запишет в лог все отклонения от нормы, и даст знать вызывающему коду о результатах. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.09.2020, 22:16 |
|
|
start [/forum/topic.php?fid=59&msg=39997741&tid=2120680]: |
0ms |
get settings: |
26ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
41ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
413ms |
get tp. blocked users: |
1ms |
others: | 286ms |
total: | 804ms |
0 / 0 |