AN
Исключения ничем не отличаются от других объектов, так что проблем никаких нет в любом случае
Size: a a a
2020 May 07
AK
не хотелось бы оставлять 2 разных потока для исключений и данных, хочется все получать в одном флоу и там уже отлавливать ошибки с .catch{} можно. Может с кодом будет более прозрачным вопрос
BP
Всем привет! Подскажите, есть ли возможность через каналы эмитить исключения, помимо непосредственных данных? Делаю обертку на API, в котором есть два отдельных источника для данных и внутренних ошибок, хотелось бы их совместить и отдавать дальше в едином флоу
Result - тип данных содержит или значения или исключения, runCatching - функция для создания Result
AN
Result - тип данных содержит или значения или исключения, runCatching - функция для создания Result
Это случай результат-или ошибка. Если ошибки независимо, а результат независимо, делаете sealed класс с двумя наследниками.
AK
Result - тип данных содержит или значения или исключения, runCatching - функция для создания Result
это я так понимаю применимо к получению данных с возможными исключениями. А я хочу разобраться как эти исключения отправлять
AN
это я так понимаю применимо к получению данных с возможными исключениями. А я хочу разобраться как эти исключения отправлять
В смысле?
BP
это я так понимаю применимо к получению данных с возможными исключениями. А я хочу разобраться как эти исключения отправлять
Ловите исключения и емитите его в канал
AN
Ловите исключения и емитите его в канал
☝️ или заварачиваете в силед класс
BP
☝️ или заварачиваете в силед класс
+
AK
благодарю 🙏
AN
благодарю 🙏
Исключения - это обычные объекты. Работа с ними не отличается от работы с другими данными, если вы не делаете throw
AK
Исключения - это обычные объекты. Работа с ними не отличается от работы с другими данными, если вы не делаете throw
просто не хотелось оборачивать данные в какой то класс, хранящий исключения. Как я понимаю от Flow<T> можно ожидать как T так и исключения при коллекте? Для этого же мы не используем Flow<Result<T>>
AN
просто не хотелось оборачивать данные в какой то класс, хранящий исключения. Как я понимаю от Flow<T> можно ожидать как T так и исключения при коллекте? Для этого же мы не используем Flow<Result<T>>
Это осмысленно если у вас исключение может быть в каждом результате. Если у вас есть независимый генератор исключений и генератор результатов, то это не имеет смысл исползовать
AK
Это осмысленно если у вас исключение может быть в каждом результате. Если у вас есть независимый генератор исключений и генератор результатов, то это не имеет смысл исползовать
то есть идея объединения ResultHandler и ExceptionHandler в Flow.catch { //exception }.onEach{ //result} - избыточна?
AN
то есть идея объединения ResultHandler и ExceptionHandler в Flow.catch { //exception }.onEach{ //result} - избыточна?
Да нет, просто если источник исключений и источник результатов не совпадают, то это ошибка проектирования
AN
Если совпадают, то да, используете обычный Result
AN
Result подразумевает, что он содержит ошибку, которая получена при генерации именно этого результата
BP
то есть идея объединения ResultHandler и ExceptionHandler в Flow.catch { //exception }.onEach{ //result} - избыточна?
Если про вычислении данных могут возникнуть ошибки и вы хотите о них сообщить то лучше использовать Result
AK
генерация ошибок и данных происходит в черном ящике API, не возьмусь судить за их архитектуру. Допускаю что ошибки могут возникать и при вычислении данных, так что их тоже надо отлавливать - но было бы здорово это делать в одном месте с исключениями API.
AN
генерация ошибок и данных происходит в черном ящике API, не возьмусь судить за их архитектуру. Допускаю что ошибки могут возникать и при вычислении данных, так что их тоже надо отлавливать - но было бы здорово это делать в одном месте с исключениями API.
Ну так тогда используете результ и не паритесь, он специально для этого сделан