Телеграмм чат группы kotlin

но лучше не вызывать функцию которая возращает Result, в Result контексте, выглядит в итоге говняно

18:50пожаловаться #1

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

Ну допустим. Так и чем тут поможет Result?

18:50пожаловаться #2

Ну допустим. Так и чем тут поможет Result?

частичная обработка ошибок на каком-то этапе. Это скоерй будет не основная йункция а делегируящая

18:51пожаловаться #3

Ну допустим. Так и чем тут поможет Result?

Когда ты хочешь возращать значения, но падать с исключениям никак нельзя, например нужно ответ на http запрос

18:52пожаловаться #4

частичная обработка ошибок на каком-то этапе. Это скоерй будет не основная йункция а делегируящая

И как это будет выглядеть? Не проще ли в try-catch обернуть?

18:53пожаловаться #5

Когда ты хочешь возращать значения, но падать с исключениям никак нельзя, например нужно ответ на http запрос

Обернуть вызов в runCatching и всё. Вопрос в том, зачем возвращать Result.

18:54пожаловаться #6

Max Rovkin in Kotlin Community

Alexander Nozik

Мысль. Если это не закрыли, то при вызове cancel раньше можно было указать причину, чтобы она прокидывалась в логи. Попробуйте указать разные причины в разных отменах

это помогло, но встаёет другой вопрос: почему при вызове job.cancelChildren всё крашится?

18:55пожаловаться #7

Boris Vanin in Kotlin Community

Alexander Nozik

Я до сих пор не сильно понимаю, как он работает.

Это этого ворнинга я думал, что понимаю

18:55пожаловаться #8

И как это будет выглядеть? Не проще ли в try-catch обернуть?

это равнозначно но зачем мне обработка ошибок в запросе ? Мне проще хранимку тогда написать 😏

18:57пожаловаться #9

Обернуть вызов в runCatching и всё. Вопрос в том, зачем возвращать Result.

ну мне в пару кейсах пригодилось

18:58пожаловаться #10

это равнозначно но зачем мне обработка ошибок в запросе ? Мне проще хранимку тогда написать 😏

Так, ладно, видимо, дальнейшее обсуждение бесполезно 🙈

18:58пожаловаться #11

Alexander Nozik in Kotlin Community

Max Rovkin

это помогло, но встаёет другой вопрос: почему при вызове job.cancelChildren всё крашится?

Пути андроида неисповедимы. Где-то это исключение перехвативается.

19:00пожаловаться #12

Alexander Nozik in Kotlin Community

Max Rovkin

это помогло, но встаёет другой вопрос: почему при вызове job.cancelChildren всё крашится?

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

19:01пожаловаться #13

Так, ладно, видимо, дальнейшее обсуждение бесполезно 🙈

(это шутка была, но мне эти try-cathy + query хранимки и напоминают, только уже в коде сервера)
Ну и я не говорю что нужно везде пихать. Нужно 1000000 раз подумать переде тем как пихать Result в API </thread>

19:01пожаловаться #14

Roman Elizarov

Раз нету стек-трейса то это какой-то баг в андроид-райнтайме или где-то есть код, который поймал исключение и вывел его в лог, но забыл записать стек-трейс.

Но ведь у этого исключения отключен стек-трейс не в дебаге

19:02пожаловаться #15

Roman Elizarov in Kotlin Community

Точно. Я про это совсем забыл!

19:03пожаловаться #16

Roman Elizarov in Kotlin Community

Надо поставить системное свойство kotlinx.coroutines.debug в значение on (cc @rovkin )