powered by simpleCommunicator - 2.0.30     © 2024 Programmizd 02
Map
Форумы / Java [игнор отключен] [закрыт для гостей] / unit-тестирование
21 сообщений из 571, страница 23 из 23
unit-тестирование
    #39997667
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
На самом деле я не хочу спорить по этой теме. Тут вроде-бы все ясно.

Но если ситуация - непредвиденная то надо упасть сразу и не растягивать удовольствие до продакшена.
...
Рейтинг: 0 / 0
unit-тестирование
    #39997673
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton
Но если ситуация - непредвиденная то надо упасть сразу и не растягивать удовольствие до продакшена.

но null может быть и нормальной ситуацией
...
Рейтинг: 0 / 0
unit-тестирование
    #39997692
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вадя
mayton
Но если ситуация - непредвиденная то надо упасть сразу и не растягивать удовольствие до продакшена.

но null может быть и нормальной ситуацией

Ты думаешь я тут в топике буду биться с тобой до конца? Да ради бога.

Возвращаяй null как предвиденную ситуацию. Насколько я понимаю ты - фулл-стекер и работаешь сам на себя?
Команды нет? Следовательно нет никаких организационных вопросов с кодом?
...
Рейтинг: 0 / 0
unit-тестирование
    #39997724
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton
Ты думаешь я тут в топике буду биться с тобой до конца? Да ради бога.
я не хочу биться, просто мне не понятно - в видео категоричное заявление - что null не надо возвращать.
что тогда возвращать если null обозначает отсутствие объекта/данных, и такое отсутствие не ошибка?
эксепщен? остановка всего приложения?
...
Рейтинг: 0 / 0
unit-тестирование
    #39997728
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Он же объяснил что возвращать. В двух вариантах.
...
Рейтинг: 0 / 0
unit-тестирование
    #39997732
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton
Я использовал пустое значение NIL или () в языках высокого уровня и это не вызывало проблем.
"()", вроде, пустой список в Lisp, NIL - null в Pascal.
Лисп оставим в покое, а разыменовывать NIL и Паскале нельзя. И в Це, с которого "списывали" Яву и в Це-с-крестами.
Система типов и операций в Java и SQL обрела общие черты или мы сейчас за концепции?
...
Рейтинг: 0 / 0
unit-тестирование
    #39997739
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton
Он же объяснил что возвращать. В двух вариантах.
в любом случае надо проверять- так почему не проще проверить на null, вместо дефолтного значения?
если по логике дефолтное значение далее может выкинуть ещё какую ошибку?
вот сделал - дефолтное - а потом другие будут разбирать - откуда такое значение? в базе нет, в источнике - нет, а значение есть.
null видишь - нет, а он есть...
в то время когда null однозначно показывает что ничего нет.
...
Рейтинг: 0 / 0
unit-тестирование
    #39997740
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Мы щас говорим о том что существуют языки где семантика операций с NULL - безопасна.
Санкционирована. Рекомендована. И даже более того. Как вы заметили в List пустой список
и NIL синонимы. Они-же являются синонимом логического результата false в булевом контексте.
Про БД мы уже говорили. Реляционная алгебра просто не существует без синонима "выколотого
элемента множества". Этот термин я не придумал. Это из учебнкиа дискретной математики.

Тоесть в этих сферах null/NIL/() это хоршо. Это гуд.

В отличие от машинно-ориентированных языков таких как C/C++ , ноль имеющий тип указателя
требует особого бережного обхождения. Тут по сути - не вопрос правильно или неправильно.
А вопрос культуры. Тоесть оставляем-ли мы после себя наследие в виде небезопасного кода
который как Чеховское Ружье стреляет во 2-м акте. Причем стреляет больно и дорого для иммиджа.

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

Кстати недавно кто-то постил NASA-вские рекомендации по надежности кода. Там - куда более
суровые требования. Требуют гарантированного доказательства завершения любого цикла.
Требуют отсутствия в коде рекурсий. И требуют какого-то лимита на уроввни вложения conditions
в камках 1 процедуры.

Ваш покорный слуга просто предложил подойти к null с точки зрения ентерпрайзных практик.

И это я пишу не для Василия.
...
Рейтинг: 0 / 0
unit-тестирование
    #39997741
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
null-ы в функциональные конвейеры не вписываются.
И вообще - try-catch это многабукав
...
Рейтинг: 0 / 0
unit-тестирование
    #39997838
забыл ник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. Sidorov
забыл ник
Если в сигнатуре метода написано Int - значит не должен возвращаться null, это хак системы типов
Int - объектный тип. null - отсутствие объекта. Если принять как данность, что объект может отсутствовать, то жить станет проще.

Жить станет проще если принять как данность, что после того как создал обьект- ты должен его за собой и прибрать. Если бы это было продуктивной идеей, то и java бы не возникла. Можно конечно добавить скорости, но вы же не хотите проседания в скорости? Знакомо?
Не понимаю упорного сопротивления в признании того что null это абсолютное и бескомпромиссное зло. Наверное на это влияет корявость реализации optional в java, из-за которого приходится писать много boilerplate. Другого объяснения у меня нет
...
Рейтинг: 0 / 0
unit-тестирование
    #39997848
забыл ник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вадя

забыл ник
Поэтому сигнатура метода четко должна указывать что значение возможно не найдено. Optional<Int>
но если вернуться к инт - что обозначает "не найдено"?
ты не будешь это проверять?
сигнатура тебе это указала и дальше что?

Смотря в каком стиле писать. В императивном, да, много мороки с optional чтобы постоянно извлекать и запаковывают назад, но я все равно за лучшую типобезопасность, даже в императивке.
В функциональном стиле все проще - допустим вызываем getEmployee() который возвращает Optional, а потом .map(getDepartment).map(getid).orElse(defaultId). То есть у тебя вся цепочка вычислений происходит в контексте Optional, нет нужды извлекать и переименовывать.. И только на самом верху, в контроллере, ты уже будешь проверять, если optional не содержит ничего - кидаем 404, содержит - возвращаем результат.
...
Рейтинг: 0 / 0
unit-тестирование
    #39997850
забыл ник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
забыл ник,

Можно конечно добавить скорости, но вы же не хотите проседания в скорости?

Читать как

Можно конечно добавить сборщик мусора, но вы же не хотите проседания в скорости?
...
Рейтинг: 0 / 0
unit-тестирование
    #39997863
chpasha
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вадя
так почему не проще проверить на null, вместо дефолтного значения?

потому что забудешь. любой, даже автор кода, рано или поздно где-то что-то забудет. в лучшем случае ты будешь использовать аннотацию @Nullable, прокидывая ее вверх по иерархии вызовов, чтоб тебе хоть IDE возможные места NPE подсветила, в худшем и этого не будет. в лучшем случае ты нарвешься сразу на NPЕ или через неделю, в худшем оно всплывет спустя два года. Так интересно совпало, я сегодня хапнул NPE в классе, который с 2016 года не менялся :)
...
Рейтинг: 0 / 0
unit-тестирование
    #39997883
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А откуда в топике появилась мысль о "проседании скорости"?
...
Рейтинг: 0 / 0
unit-тестирование
    #39997885
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
забыл ник
у тебя вся цепочка вычислений происходит в контексте Optional, нет нужды извлекать и переименовывать.. И только на самом верху, в контроллере, ты уже будешь проверять, если optional не содержит ничего - кидаем 404, содержит - возвращаем результат.
Больше смахивает на результат работы кода, который толком никому не нужен, а не на какую-то киллер-фичу. Вот, к примеру, у меня есть желание иметь возможность хоть какой-нибудь отладки, поэтому я хочу в условных переходах понатыкать логирования, вот куда мне это логирование вставлять если "вся цепочка вычислений происходит в контексте Optional"?
Во-вторых, судя по всему в жаве никто тупняк с женериками убирать не собирается, поэтому метод хоть и может возвращать Optional<?>, а вот чтобы метод мог принимать Optional<?> в качестве аргумента ну уж очень сильно не рекомендуется.
Вот без решения по крайней мере этих двух проблем говорить о повсеместном использовании Optional<?> в жаве не приходится.
...
Рейтинг: 0 / 0
unit-тестирование
    #39997893
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
забыл ник
null это абсолютное и бескомпромиссное зло
А ещё деление на ноль, исключения ввода-вывода и нарушение условий технического задания. Но программисты - не слабаки, и в борьбе за светлое будущее не оставят камня на камне.
...
Рейтинг: 0 / 0
unit-тестирование
    #39997896
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В топике NPE (не в главном а в том который спонтанно возник) есть две линии спора.

Одна линия - предпринять действия для уменьшения возможности получения этого дефекта
и вторая линия - не делать ничего.
...
Рейтинг: 0 / 0
unit-тестирование
    #39997944
забыл ник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Basil A. Sidorov
забыл ник
null это абсолютное и бескомпромиссное зло
А ещё деление на ноль, исключения ввода-вывода и нарушение условий технического задания. Но программисты - не слабаки, и в борьбе за светлое будущее не оставят камня на камне.

Ты так удивляешься, как будто вышеперечисленное есть норма.
Переполнение стека, разыменование указателя на несуществующую область памяти, утечка файловых указателей тоже когда-то казались нормой, но к счастью инструменты а главное ремесло программирования не стоит на месте. И только ретрограды злобно кричат вслед и машут кулачками.
Священный грааль программирования как раз и состоит в том что все ошибки должны быть автоматически отловлены еще на этапе компиляции. К сожалению из-за halt-problem это невозможно, но это не повод не пытаться приблизиться к идеалу. ЕДинственные ошибки, на которых должен концентрироваться программист(не системный) - это ошибки в бизнес-логике, да и те можно сводить к минимуму с помощью системы типов
...
Рейтинг: 0 / 0
unit-тестирование
    #39997945
забыл ник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Панфилов
Больше смахивает на результат работы кода, который толком никому не нужен, а не на какую-то киллер-фичу.

Поясни, не понял что к чему.

Андрей Панфилов

Вот, к примеру, у меня есть желание иметь возможность хоть какой-нибудь отладки, поэтому я хочу в условных переходах понатыкать логирования, вот куда мне это логирование вставлять если "вся цепочка вычислений происходит в контексте Optional"?

Отладки чего? Что касается Java, я с тобой не спорю. И в принципе понимаю сопротивление против Optional, потому что его выгода не очевидна. Но мы вроде как говорим о проблеме null в более широком смысле? На примере скалы - если тебя нтересует присутствие\отсутствие значения, независимо от причины - тогда Optional и логирование бессмысленно. Если нужно знать что конкретно и где свалилось - Either<Error, Result> - в каждой ветви ты можешь либо пробросить результат дальше либо закончить вычисление с Error("Причина"). Я работаю на скала+спарк, так вот - мне не только логгирование но и дебаггер то особо не нужен, включаю раз в три дня

Андрей Панфилов

Во-вторых, судя по всему в жаве никто тупняк с женериками убирать не собирается, поэтому метод хоть и может возвращать Optional<?>, а вот чтобы метод мог принимать Optional<?> в качестве аргумента ну уж очень сильно не рекомендуется.

Согласен, так а зачем передавать optional в метод? Твои бизнес функции должны быть типа A -> B, а вот вызывать их или нет будет решать контекст Optional, что как раз и является киллер-фичей.

Андрей Панфилов

Вот без решения по крайней мере этих двух проблем говорить о повсеместном использовании Optional<?> в жаве не приходится.

Ну в жаве да, но ты в целом солгасен с утверждением что null это зло? И если бы был адекватный инструментарий то им и надо было бы пользоваться?
...
Рейтинг: 0 / 0
unit-тестирование
    #39997952
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
забыл ник
Поясни, не понял что к чему.
Петя работает в отделе А, отделом А руководит Вася, у меня бизнес логика в духе: хочу узнать кто руководитель Пети. Решение через Optional в духе:

Код: java
1.
return Optional.ofNullable(employee).map(Employee::getDepartment).map(Department:getManager)


мне совершенно не нравится тем, что его невозможно сопровождать с точки зрения поддержки, т.е. прилетает запрос от пользователя в духе: "я тут нажимаю кнопку, а мне вместо ожидаемого результата приходит что-то не то, что я ожидаю", наиболее приемлемым вариантом был бы такой: поддержка включает дебаг, отжимает кнопку и видит в логе, что Петя не привязан к отделу, или что у отдела нет руководителя, т.е. в таком случае сопровождаемость решения зависит от того есть логирование в условных переходах или нет (ну т.е. достаточно только код писать нормально), а в случае цепочки map условные переходы есть, а логирование вставлять некуда, т.е. от null вроде как избавились, а решение при этом получилось совершенно несопровождаемым, потому что нужно на любой чих лезть в код и угадывать что там там не так

Андрей Панфилов
На примере скалы - если тебя нтересует присутствие\отсутствие значения, независимо от причины - тогда Optional и логирование бессмысленно. Если нужно знать что конкретно и где свалилось - Either<Error, Result> - в каждой ветви ты можешь либо пробросить результат дальше либо закончить вычисление с Error("Причина"). Я работаю на скала+спарк, так вот - мне не только логгирование но и дебаггер то особо не нужен, включаю раз в три дня
ну мы же вроде на прошлых страницах обсудили, что матрешки из Either/Optional - ну откровенно так себе, ну и скала никак от ошибок в коде не спасает (вроде тоже продемонстрировано было), а насчет дебагера... ну вот я в жаве его на своем коде практически не запускаю (т.е. это еще реже чем раз в три дня) и что с того?

Андрей Панфилов

Согласен, так а зачем передавать optional в метод? Твои бизнес функции должны быть типа A -> B, а вот вызывать их или нет будет решать контекст Optional, что как раз и является киллер-фичей.
Как это зачем передавать? Мне вот тут взяли и вернули из метода Optional<?> (я так понял противники NULL как раз эа это и топят, что раз метод возвращает Optional<?>, то это точно не null, но внутри может быть empty), что мне с этим Optional<?> делать-то? Я вот хочу его/значение в другой метод передать (у меня же сложная система, а не код из пары строк), каким образом его предлагается передавать-то? через orElse(null)? тогда смысла никакого в этом Optional<?> нет. Может через map? Оно выглядит более-менее пристойно только для методов с одним аргументом, а если аргументов несколько, да к тому же еще и претендующие на защиту от null, то на выходе получается хрень, а никакого другого вменяемого механизма-то и нет (если бы было хитрое статическое связывание T и Optional<T> было бы интересно, но что-то кажется что рвало бы шаблоны только в путь: вроде метод вызываем, а он не вызывается, и лога соответствующего нет нигде), в итоге получается что код в конкретном методе возможно и null-safe, но все это обильно связано соплями (еще и hot deploy ничерта не работает).

Андрей Панфилов
Ну в жаве да, но ты в целом солгасен с утверждением что null это зло?
Я считаю, что:
- информация об отсутствии данных, это тоже данные, вадя тут совершенно прав, если бы был вменяемый механизм разграничения, можно было бы по крайней мере задуматься об использовании, а бежать и переделывать все на Optional<?> - толку мало, это как сейчас некоторые индивидуумы начали резво избавляться от интерфейсов и оперировать исключительно интерфейсами из java.util.function, в итоге с кодом ничего толком сделать нельзя кроме как удалить и написать правильно
- в жаве слишком мало налов, нужно было развивать первоначальные идеи Кодда и делать несколько видов
...
Рейтинг: 0 / 0
unit-тестирование
    #40000584
Псевдомизантроп
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Панфилов
забыл ник
Поясни, не понял что к чему.
Петя работает в отделе А, отделом А руководит Вася, у меня бизнес логика в духе: хочу узнать кто руководитель Пети. Решение через Optional в духе:

Код: java
1.
return Optional.ofNullable(employee).map(Employee::getDepartment).map(Department:getManager)


мне совершенно не нравится тем, что его невозможно сопровождать с точки зрения поддержки, т.е. прилетает запрос от пользователя в духе: "я тут нажимаю кнопку, а мне вместо ожидаемого результата приходит что-то не то, что я ожидаю", наиболее приемлемым вариантом был бы такой: поддержка включает дебаг, отжимает кнопку и видит в логе, что Петя не привязан к отделу, или что у отдела нет руководителя, т.е. в таком случае сопровождаемость решения зависит от того есть логирование в условных переходах или нет (ну т.е. достаточно только код писать нормально), а в случае цепочки map условные переходы есть, а логирование вставлять некуда, т.е. от null вроде как избавились, а решение при этом получилось совершенно несопровождаемым, потому что нужно на любой чих лезть в код и угадывать что там там не так


Если на входе теоретически может быть мусор, то должен быть класс-валидатор, который проверит всё в самом начале и запишет в лог все отклонения от нормы, и даст знать вызывающему коду о результатах.
...
Рейтинг: 0 / 0
21 сообщений из 571, страница 23 из 23
Форумы / Java [игнор отключен] [закрыт для гостей] / unit-тестирование
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]