not just fuel. Same issue should exist in retrofit

never used retrofit

my solution for now until i figure out how to deal with this better is..

loop@ while(true)

and

continue@loop

failsafes yay

Yay

found another bug.. or rather the fix for a bug when a Deserializer throws a exception it is catched properly .. except when its a coroutine pipeline becaue at some point it casts everything to FuelError .. without checking and wrapping

and here it is.. with a test even; https://github.com/kittinunf/Fuel/pull/500

with this i am sure that any kind of exception is handled and wrapped properly

i guess i should have called the brach fix or hotfix.. i did not know that it would be this easy when i started

@kittinunf do zou know what caused that to break? all tests pass fine locally and it seems like the last step

./add_review.sh

fails

oh i did not see the lint failed

So its all good?

this content-length mismatching could be something FUel could be catching in a error.. but only on some cases apparently

anyways that change makes it so that all errors are captured.. am i the only one using fuel-coroutines ?

@kittinunf did you see this ? https://github.com/kittinunf/Fuel/pull/497#discussion_r230468991

my PRs are ready

last one https://github.com/kittinunf/Fuel/pull/500/files#r230589685 🙏

sorry i couldn’t catch it earlier

and i missed it too

fix pushed

one last question though

what’s the error if you don’t put the type in here

mapError <T, Exception, FuelError> {

Just

mapError {

it errors at runtime

i am guessing because it implicitly takes the types from the return

and casts any Exception to FuelError

i really like how Result handlles the errors and error mapping though

well I like it too

that’s why i made it

haha