Error handling

How error handling works: a concrete example

Picture a customer tapping "Pay" in a mobile app. Several things can go wrong: the phone loses signal, the payment provider times out, the card is declined, or the server has a bug.

Poor error handling looks like this: the app freezes, shows a vague "Something went wrong," or, worse, charges the card twice when the customer taps again.

Good error handling treats each case differently:

• No connection: tell the customer they are offline, keep their cart and offer to retry.
• Timeout: ask the server whether the payment went through before retrying, so nobody is charged twice.
• Card declined: show a clear message and let the customer choose another payment method.
• Server bug: show a calm message, record the full technical details with a reference ID, and alert the development team.

The customer sees something helpful. The team gets what it needs to fix the problem.

Types of errors software has to handle

• User input errors: an invalid phone number or a missing field. Best caught with validation before anything is sent.
• Expected operational errors: network failures, timeouts, missing files or a third-party service that is down. These will happen, so plan for them.
• Programmer errors (bugs): code that assumes something that is not true. These should be logged loudly and fixed, not hidden.
• System errors: running out of memory, a full disk, a database that is unavailable. Usually handled at the infrastructure level with monitoring and automatic recovery.

Core error handling techniques

• Validation at the edges: check input in the app, and again on the server.
• Exceptions and result types: language features such as try/catch or Result types that make code deal with failure explicitly.
• Retries with backoff: try again after a short, growing delay for temporary failures, but only for actions that are safe to repeat.
• Timeouts: never wait forever on another service.
• Fallbacks: show cached data, a simplified screen, or queue the action for later when something is unavailable.
• Logging and monitoring: record errors with context and send alerts, so the team knows before customers complain. See telemetry.

Common error handling mistakes

• Swallowing errors: catching an error and doing nothing, so failures disappear silently.
• Showing raw technical messages to users, which confuses them and can reveal internal details to attackers.
• One generic message for everything, so users cannot fix problems they could have fixed themselves.
• Retrying unsafe actions, such as payments or order creation, without protection against duplicates.
• Logging too little, so errors cannot be reproduced, or logging too much, including passwords or personal data.

What to ask your development team

• What does the user see when the network drops or a service is down?
• How do we find out about errors in production, and how quickly?
• Are payments and orders protected against duplicate submission?
• Are error messages clear and translated in every language the app supports, including right-to-left languages?

If you want software that fails gracefully and tells you when something is wrong, our custom software development team can help.