ой что это я, тесты же вперёд

Ну нет, работа по jdbc, с дисковым io тот ещё адок был

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

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

Потому что ними почти никто не пользовался, все фреймворки оборачивали их в непроверяемы.

Тебе же никто не мешает их ловить и сейчас.

просто твои сигнатуры методов станут чище

ой что это я, тесты же вперёд

по фрейду

да дело не в ловить. как мне узнать побыстрому какие эксепшены могут прилететь из этого метода?

доки

ну и сам код.

Ну передай налл, что ты там с этим опшном потом..

Один раз можно :-)

Ну передай налл, что ты там с этим опшном потом..

ну тут ещё наследие жабки, те же мапы, вполне могут вернуть налл, что уж там

Один раз можно :-)

прямо змий искуситель

я писал if (value != null), мой отец писал, и его отец, так что и ты пиши, а то посмотрите на него, опшналы захотел, ишь что удумал.

я писал if (value != null), мой отец писал, и его отец, так что и ты пиши, а то посмотрите на него, опшналы захотел, ишь что удумал.

ну к слову Optional тоже может быть null и идея постоянно об этом сообщает, а ты уверен что аргумент в этом методе Optional, это же потенциальный NPE,давай по старому, а

ну к слову Optional тоже может быть null и идея постоянно об этом сообщает, а ты уверен что аргумент в этом методе Optional, это же потенциальный NPE,давай по старому, а

в каких случаях optional может быть null? Если только сам будешь вместо него null передавать/возвращать

в каких случаях optional может быть null? Если только сам будешь вместо него null передавать/возвращать

ага,

никтож не мешает

ну к слову Optional тоже может быть null и идея постоянно об этом сообщает, а ты уверен что аргумент в этом методе Optional, это же потенциальный NPE,давай по старому, а

Это знатный троллинг, написать метод который возвращает null вместо Optional

не

в аргументах

но в целом да, можно и так )

в том-то и дело :)

ага,

Ну так не надо так делать :( на самом деле, заметил, что действительно с тех пор как я перестал писать на джаве и пишу на скале, не ловил NPE, только в каких-то джавовских либах с какими-то рефлекшенами типо логгеров, которые сами внутри себя что-то сеттят

то вы еще в Stream<> не пробовали null передавать наверное

Ну так не надо так делать :( на самом деле, заметил, что действительно с тех пор как я перестал писать на джаве и пишу на скале, не ловил NPE, только в каких-то джавовских либах с какими-то рефлекшенами типо логгеров, которые сами внутри себя что-то сеттят

как уже выше написали нормально делай нормально будет

как уже выше написали нормально делай нормально будет

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

то вы еще в Stream<> не пробовали null передавать наверное

Collectors.toMap может легко кинуть NPE если значение будет null, не ключ а именно значение

тоесть мапишь ты какой-либо лист с pojo на k->v и вдруг v у тебя null, и ты думаешь да насрать, что будет, в мапе же может значение быть null, и получаешь NPE

List<Integer> is = Arrays.asList(null, 1,2,3); is.stream().findFirst().ifPresent(System.out::println);

вот что по вашему это вернет?

NPE

вот что по вашему это вернет?

undefined behaviour

или ничего

но почему?

потому что рукажопы писали )

со stream api всегда так - никогда не знаешь, когда оно достанет дробовик и пальнет тебе в лицо

null стало можно в коллекции класть?

или всегдаможно было

а почему нет? О_О

хз

null стало можно в коллекции класть?

а раньше нельзя было?

добро пожаловать в яву

null стало можно в коллекции класть?

коллекции же из референсов, так почему бы нет

)))

еще варианты? )

варианты?

та херня NPE кинет, да.

потому что findFirst делает Optional.of

всё, вспомнил, что да слишком избалован optional типами в современных языках программирования

коллекции же из референсов, так почему бы нет

ну я на вот это сообщение )

какого хера там опшнл тогда не понятно

на случай пустого стрима видимо

потому что findFirst делает Optional.of

именно of?

йеп

не ofNullable

ну ооок

но с коллектом меня тоже смутило

не очевидно нифига

ну и в общем поработаешь так со стримапи, поработаешь с опшнлами, поплачешь что нету either, да и махнешь рукой

но ура, в 9-ой яве теперь есть Optional::stream

еще нет каринга

и Optional::or

каринга много где нет :( но в яве его можно симулировать, правда без lhs инференса это такой будет шум в коде :))

а в котлине есть currying?

void ifPresentOrElse(Consumer<? super T> action, Runnable emptyAction)

ERROR: S client not available

huehuehue

вроде нет

буэээ

void ifPresentOrElse(Consumer<? super T> action, Runnable emptyAction)

ну сейчас есть orElseGet(Supplier)

лет через 5 там в api будут все возможные комбинации слов if, else, get, or, present

но все ‘то выглядит как минимум странно )

вот эти вот CS <-> CF вот прямо раздражает, зачем так сделано, что толку от интерфейса если его можно однозначно привести к имплементации

https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletionStage.html#toCompletableFuture--

как бе

никто не мешает тебе писать

Function<Integer, Function<Integer, Function<Integer, Integer>>> sum3 = a -> b -> c -> a + b + c; System.out.println(sum3.apply(2).apply(1).apply(0));

кроме, конечно же, здравого смысла :)

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

кроме, конечно же, здравого смысла :)

ну так-то конено не мешает )

дык был бы lhs inference..

как и null вместо Optional передать

В груви есть каррирование

:) вот бы там еще типы были

Они есть. Просто когда предлагаешь их использовать, почему то у другой стороны возникает вопрос: "зачем мне груви без динамики" ))

ну другая сторона видимо любит рефакторить полным реврайтом проекта

Я вообще не любитель закладывать груви в ядро

я вообще удивлен что на нем до сих пор кто-то пишет

А что тебя удивляет?

Я пока не знаю более гибкого языка

лисп

Для jvm

JRuby разве что

Не более но может конкурировать

ну мы ж на жвм пишем чтоб компилятор ловил как можно больше багов

Мы пишем чтобы решать задачи

http://i.imgur.com/OsVN8P5.png

Для jvm

clojure