오류를 UI 메시지로 매핑

A user should never see SerializationException on screen. Your job is to translate technical failures into calm, human sentences.

Group failures into a few error kinds like network, server and unknown. Each kind maps to one clear message the apps can show.

Extend your Failure to hold an ErrorKind, not just a raw string. The UI then decides wording instead of trusting backend text.

Convert exceptions to an ErrorKind right where you catch them. After this point your code speaks only in friendly, stable categories.

Write one function that turns an ErrorKind into display text. Keep it in shared code so both apps phrase errors identically.

Real apps translate messages. Let each platform localize the kind, so the shared layer passes the category and the UI picks the language.

Your rules return an ErrorKind, never a hardcoded sentence. Wording can change anytime without touching business logic.

A network error might show a retry button while a server error shows a support link. The kind drives both the words and the action.

Always include an UNKNOWN kind. Unexpected failures still get a polite, generic message instead of a blank or scary screen.

Because the mapper is pure, you can test it in commonTest: feed an exception, assert the kind, with no UI or device involved.

Now errors travel as typed kinds from catch to screen, giving Android and iOS one consistent, friendly story for every failure.

Consider what the shared layer should expose to the UI.

You categorized failures into ErrorKinds, mapped exceptions at the boundary, and let each UI localize and act on the kind for a friendly experience. 💬