Error Handling

Error handling is the discipline of deciding what a program does when an operation cannot complete as expected. It covers structured mechanisms such as exceptions, returned error values, and cleanup clauses, plus the judgment of when to handle, wrap, translate, or propagate a failure so problems stay visible and recoverable.

itSoftware engineering

Don't Panic: Error Handling

Error handling is the part of a program that decides what happens when normal completion is no longer available. That sounds like an afterthought until the first failure deletes context, leaks a resource, and reports the operational equivalent of something went wrong. At that point it becomes architecture with a traceback.

An error path is still a path. It has inputs, outputs, cleanup, and a caller that needs to decide what to do next. Exceptions move control to a handler. Returned values keep failure visible in the function result. Different languages prefer different mechanisms, and fighting the language usually produces more ceremony than clarity.

The useful question is where the right context exists. A library may know that parsing failed on a field. The application knows whether to skip the record, reject the file, or stop the workflow. Let errors pass through layers that cannot decide, but add context when a layer knows what it was trying to do.

Preserve causes. A database timeout can become a service unavailable error at an API boundary, but the original failure should remain attached for diagnosis. Cleanup is equally non-negotiable: files, locks, transactions, sockets, and temporary data need release paths for success, failure, and early return. The failure will not politely wait for a convenient branch.

Testing is where the discipline becomes real. Force the file open to fail. Force the dependency to time out. Force validation to reject input. Assert the type, message, cause, cleanup, and report. A suite that only tests successful work has not tested the program.

Start with the Practice Reference to classify failures and boundaries. Use the Exercise to design an import job's failure behavior. The Cheatsheet keeps mechanisms, cleanup, propagation, reporting, and testing in one view. The goal is not a program that never fails. The goal is a program that fails legibly, contains damage, and gives the next layer enough truth to act.

Don't Panic: Error Handling

Relevant careers