Hi Guys, Any clues on how to handle com.squareup.m...

# android

[Wishnuprathikantam]

Hi Guys, Any clues on how to handle com.squareup.moshi.JsonDataException to show an error message to the user without crashing the app unexpectedly. I don't have control over the API response so need to handle this gracefully and let the user know the app isn't compatible with the backend.
I'm using Retrofit + OKHttp + Moshi.
Any help is appreciated. Thanks.

FATAL EXCEPTION: DefaultDispatcher-worker-3
    Process: com.myapp, PID: 18030
    com.squareup.moshi.JsonDataException: Required value 'fakeParam' missing at $
        at com.squareup.moshi.internal.Util.missingProperty(Util.java:660)
        at com.myapp.data.models.DeviceInformationJsonAdapter.fromJson(DeviceInformationJsonAdapter.kt:109)
        at com.myapp.DeviceInformationJsonAdapter.fromJson(DeviceInformationJsonAdapter.kt:22)
        at com.squareup.moshi.internal.NullSafeJsonAdapter.fromJson(NullSafeJsonAdapter.java:41)
        at com.squareup.moshi.JsonAdapter$2.fromJson(JsonAdapter.java:205)
        at retrofit2.converter.moshi.MoshiResponseBodyConverter.convert(MoshiResponseBodyConverter.java:45)
        at retrofit2.converter.moshi.MoshiResponseBodyConverter.convert(MoshiResponseBodyConverter.java:27)
        at retrofit2.OkHttpCall.parseResponse(OkHttpCall.java:225)
        at retrofit2.OkHttpCall$1.onResponse(OkHttpCall.java:121)
        at okhttp3.internal.connection.RealCall$AsyncCall.run(RealCall.kt:519)

[Tim Oltjenbruns]

Not Kotlin, but I’ll volunteer to help this one. Make fakeParam not required. I think you may be able to do that by making the type nullable.

[Tim Oltjenbruns]

And then you can check whether it’s null or do any other required validation, and decide to show an error in the UI

[Tim Oltjenbruns]

There are other ways of doing this, but this way improves the rest of your code by appropriately recognizing that the value can sometimes be null. kinda Kotlin, which is why I answered.

[Wishnuprathikantam]

That solves that issue for now but there are parameters that potentially can exist or don't exist in the future. Either I've to make everything nullable or use try-catch everywhere. Can we write some kind of converter for Moshi to handle these cases?
Thanks for replying.

[Tim Oltjenbruns]

Yes you can create a converter for Moshi. I don’t recommend that because it doesn’t let the rest of your code benefit from knowing which fields may be null.

[Tim Oltjenbruns]

Maybe some high level try catch all as a last resort, to show an error and help identify these cases. But I think your data model will benefit from properly identifying which fields can and cannot be null

[Tim Oltjenbruns]

If your API is unstable, that’s a totally separate problem. If you can’t help make the API stable, or signal to the API which version of the response model you want, then yes I would make everything nullable.

[Tim Oltjenbruns]

And use separate models in the rest of my code after they pass through the validation.

Because if you do it in a Moshi converter, half your validation code is in Moshi converters and half is elsewhere. I think its better all of that response model validation live in the same place.

[Tim Oltjenbruns]

But if you’d rather just use a Moshi converter and learn the consequences on your own, feel free to do that. It should be possible!

[Wishnuprathikantam]

Agreed. For now, I'll just make everything nullable and use the combination of fields to detect and let know the user that the API has changed. Thank you.

[Sanjeeviraj M]

or you can write an interceptor and return a response body which won't crash your app

[Tim Oltjenbruns]

You could, but should you? Depends on the use case. Falls into a similar boat as the Moshi converter. You can but should you?

[gildor]

Our experience shows that having everything nullable (or use default values, depending on your case) is the way to go which allows you to handle missing API fields correctly and only for places where it is important instead of fail whole request

Optional params is really the only way to handle API evolution (or just have a very strict API evolution process, but as you said you don't have control over this API). This is also the reason why proto3 has only optional fields out of the box

I don't really think that there is a good way to handle it on the level of retrofit adapter