ดักจับข้อผิดพลาดเครือข่ายและการแยกวิเคราะห์

Most failures appear at two spots: the network call and the JSON parse. Catching them here keeps the rest of your shared code clean and calm.

Put the Ktor request and the decode inside a single try block. One guarded spot is easier to reason about than scattered checks.

A dropped connection throws an IOException. Catch it and turn it into a clear Failure your UI can present as a connectivity problem.

When JSON does not match your model, kotlinx.serialization throws a SerializationException. Catch it separately so you know data, not the network, was bad.

List the specific exceptions first and a broad Exception last. Kotlin matches top to bottom, so narrow types must come before the catch-all.

Inside each catch, build a Failure and return it. Rethrowing would just push the crash up to the apps you are trying to protect.

This guarding belongs in shared code, right around the call. Both Android and iOS then receive the same safe Result with no extra work.

A reachable server can still answer 404 or 500. Check the response status and map non-2xx codes to a Failure too.

Never leave an empty catch. Log the cause before returning Failure so you can still debug what really happened on a device.

Kotlin offers runCatching to wrap a block into a Result-like value, a tidy alternative when you do not need custom catch logic.

Network and parsing errors now flow through one funnel into your Failure type, so callers handle both with the same simple branch.

Think about how kotlinx.serialization signals trouble.

You wrapped the call in try, caught IOException and SerializationException separately, mapped bad status codes, and returned tidy Failures from shared code. 🛡️