
Phil
14.02.2018
10:25:37
String - да, но нельзя получить список всех доступных вариантов )
Тогда уж лучше общий enum на все допустимые виды ошибок.

Kirill
14.02.2018
10:26:07

Anton
14.02.2018
10:26:11

Phil
14.02.2018
10:26:19
Очень похоже на checked exceptions, только без checked и с возможностью "умолчательного" проброса из вызываемых методов.

Google

Kirill
14.02.2018
10:26:32
А потом их суммировать, например ))

Phil
14.02.2018
10:26:48
Тут главное - это уметь видеть в коде верхнего уровня все, что могло произойти.
Странно, что это никому не требовалось никогда )

Igor
14.02.2018
10:27:44
Что то это похоже на “алгебраические эффект”

Anton
14.02.2018
10:27:44
Всем такое требуется, только решаем это мы простыми способами ?

Phil
14.02.2018
10:29:53
Ну, простыми и мы решаем. Но хочется простым и красивым.

Mikhail
14.02.2018
10:30:46
ну тут такая палка о двух концах
либо мы можем проверить все исключения, которые только могут быть и тогда нам надо их указать заранее
либо мы можем ихрасширять извне по ходу написания кода и тогда как компилятор это проверит?

Phil
14.02.2018
10:31:42
Вообще, решение можно сделать даже на уровне IDE )
Возможно, что это даже было бы проще всего )

Kirill
14.02.2018
10:32:11

Денис
14.02.2018
10:32:43

Serezha
14.02.2018
10:33:01

Google

Anton
14.02.2018
10:33:11
Как-то да. Читаю чатик - и тут предлагают какие-то невообразимые вещи, которые сделают наш код только сложнее.

Phil
14.02.2018
10:33:39
Типа аннотации @WithError() на методе, учета через call stack всех таких аннотации и аннотации вида
@CheckError на when, которая ругается, если список не совпадает с суммой всех @WithError.
Да, если есть какой-то хитрый вызов, то надо будет на нем указывать вручную, что из @WithError он может вернуть.

Anton
14.02.2018
10:34:30

Phil
14.02.2018
10:35:03
Зачем?
Надо или найти время и самому запилить или надеятся на других. Времени нет (

Anton
14.02.2018
10:35:40
Это намек на то, что это очень сложно ?

Phil
14.02.2018
10:36:40
Для языка - да. Для IDE, где тот же call stack и так уже есть - несколько проще.
Ну, примерно как @NotNull, подозреваю )

Kirill
14.02.2018
10:37:44

Phil
14.02.2018
10:38:22
Нет, проверки при прочих инспекциях )

Kirill
14.02.2018
10:38:47
Плагин для иде такой пишется за вечер. Надо только аккуратно по psi походить
*за неделю вечеров

Phil
14.02.2018
10:39:27
Студенческий проект в JB?
(Я, правда, думал, что такой плагин уже кто-то написал и мне посоветуют).

Kirill
14.02.2018
10:40:25

Phil
14.02.2018
10:42:41
Ну, надо, что бы кто-то изнутри предложил при очередном выборе курсовых )
Я уже не могу (

Andrew
14.02.2018
10:44:54

Alexey
14.02.2018
13:47:53
Товарищи котлинисты, подскажите какие либы для работы поверх jdbc у вас в чести?
Чтобы без jpa и вот этого всего

Google

Alexey
14.02.2018
13:49:42
Смотрю на вот эту https://github.com/seratch/kotliquery но апи чутка ублюдочный

Руслан
14.02.2018
13:49:58
Кажется чуть выше обсуждали: JOOQ, Apache Caynne
Есть еще нативный Exposed

Alexey
14.02.2018
13:50:41

Руслан
14.02.2018
13:52:49
Ну там нету магии я бы сказал, наоборот все достаточно просто
наверно зависит от уровня знания котлина
потому что вся магия имеено в нем

Alexey
14.02.2018
13:53:10
Вот в языке есть фича data class, но почти все либы хотят чтобы были мутабельные классы и вот это всё

Andrew
14.02.2018
13:56:16
В этом и плюшка нативных котлин-либ :)
Джава-мир не сильно дружит с иммутабельностью.

Anton
14.02.2018
13:56:26
Это неправильные либы и они дают неправильный мед.

Alexey
14.02.2018
13:56:37

Andrew
14.02.2018
13:56:43
Угумс.

Alexey
14.02.2018
13:57:31
Угумс.
Ну это всё хорошо живёт только в сингл треде
Так что это скорее недостаток, который достался от всяких jpa

Mi
14.02.2018
13:58:01

Руслан
14.02.2018
13:58:56

Alexey
14.02.2018
13:59:11
Для этого придумали пулы
Вот есть простой кейс, мне надо за одну операцию сходить в базу, затем с этими данными сходить в пару внешних сервисов, и потом еще что поделать с этими данными
http клиенты уже давно есть асинхронные, так что блокируюсь я только на jdbc, а остальной код вполне может быть асинхронным

Google

Alexey
14.02.2018
14:04:32

Andrew
14.02.2018
14:06:02
Вероятно, я не сильно понял ваш последующий вопрос, ибо "угумс" я поставил после правки и в продолжение её.
В котлине принято по-умолчанию делать поле final и думать, где этот модификатор можно убрать, в джаве обычно наоборот. Следовательно большинство библиотек просто не обрабатывают кейсы с final-полями, ибо с mutable данными работать проще.
В свете этого и появляются всякие реалмы, которые отказываются работать в многопоточном окружении.
(Вроде давно уже поправили это, но я давно андроидом не занимаюсь и актуальной информацией не владею).

Alexey
14.02.2018
14:09:30
А кто говорил про андроид

Andrew
14.02.2018
14:09:39
Я не говорю, что так делают все, но примеров достаточно.

Quantum Harmonizer
14.02.2018
14:10:01

Andrew
14.02.2018
14:10:03
А под андроид не на джаве пишут и туда не тянут джава-библиотеки? Просто пример привёл, с которым знаком.
В JavaFX тоже с иммутабельностью всё плохо, если вам Андроид не подходит. Серверами профессионально не занимаюсь, примерами отсюда не поделюсь, но вы лучше меня знаете, как там дела.

Quantum Harmonizer
14.02.2018
14:12:39

Alexey
14.02.2018
14:14:04
Ясно понятно, котлин еще не оброс котлин вей либами особо

Andrew
14.02.2018
14:14:12
Да не обязательно так строго. Местная реактивщина в любом случае предполагает рассматривать изменения не модели в целом, а каждой отдельной проперти. Фреймворк сам к этому толкает.

Quantum Harmonizer
14.02.2018
14:14:40

Andrew
14.02.2018
14:14:54
TornadoFX со своими ItemViewModel, конечно, помогет.

Quantum Harmonizer
14.02.2018
14:14:59

Andrew
14.02.2018
14:15:35
Я не говорю, что это неудобно, я говорю, как оно сделано. И любые проперти в итоге можно менять исключительно в JavaFX thread.
С JDBC тоже вполне можно работать. Суть та же.

Alexey
14.02.2018
14:18:03

Quantum Harmonizer
14.02.2018
14:19:08

Google

Alexey
14.02.2018
14:19:27

Quantum Harmonizer
14.02.2018
14:19:51
Либы где, лебовски?
персистентные коллекции, например, в разработке, но вроде можно взять скаловские

Andrew
14.02.2018
14:20:05
В котлине есть корутины, всё чувствительное к потокам счастье заворачивается в собственные диспетчеры, с остальным тоски не знавал пока.

Alexey
14.02.2018
14:20:51
Ну вот да, можно попробовать всё навернуть в рутины и прокидывание сессий, но опять же придётся достать напильник

Phil
14.02.2018
14:21:44
Ну и это пока транзакций нет и пока коннекций к БД не жалко.

Quantum Harmonizer
14.02.2018
14:22:44

Andrew
14.02.2018
14:23:14
В напильнике нужды пока тоже не было, на тему раскидывания по потокам достаточно того, что есть в kotlinx.coroutines (либо ентот самый диспетчер JavaFx, либо возможность создать контекст из single thread / fixed thread pool).

Alexey
14.02.2018
14:24:14

Andrew
14.02.2018
14:26:02
Тут ничего не подскажу, ибо не доводилось делать самому.

Phil
14.02.2018
14:26:10
Если есть транзакции, то корутины не очень помогут, jdbcconnection так не работает, насколько помню.

Alexey
14.02.2018
14:27:12
собственно с чего всё и началось

Alexey
14.02.2018
14:27:31

Phil
14.02.2018
14:27:57
Не помню, смотреть надо и, боюсь, в конкретном драйвере.

Alexey
14.02.2018
14:28:17
сессия никак не привязана к треду если что

Alexey
14.02.2018
14:28:33

Alexey
14.02.2018
14:29:06
Пришли скаланы, сразу меня поняли, вот это я понимаю

Alexey
14.02.2018
14:30:08
насколько я понимаю ничего что работает в нововй парадигме пока нет. все что есть тонкий слой над существующими java решениями

Alexey
14.02.2018
14:31:41