Proper Error Handling and Ensuring Correctness in Backend Development

Beginners often learn error‑handling mechanisms (e.g., Java exceptions) without realizing that the true purpose of handling errors is to write correct programs.

What constitutes "correctness" is defined by the problem being solved; for a web API that expects an age between 0 and 150, invalid input should be validated early and the error propagated to the front end for user feedback.

When a backend service uploads an avatar to cloud storage and receives a 500 error, a retry may help, but if retries fail a fallback (e.g., another storage server) or a user‑visible error message should be used.

NullPointerException (NPE) usually indicates a programmer bug; continuous monitoring and log‑based alerts are needed to detect and fix such issues promptly.

Out‑of‑Memory (OOM) crashes require container orchestration (e.g., Kubernetes) to restart instances, but stateful services must also restore data to a consistent state after a restart.

The article highlights the concept of "external containers" such as a master thread manager, a web server, or the operating system, and notes that Erlang embeds a supervisor‑worker model into the language.

Web applications can often bubble exceptions to a central handler because user‑originated errors are best presented to the user, backends are typically stateless, and database transactions protect data integrity.

However, these assumptions break when business logic is stateful, when transactions are not used, or when microservice calls modify memory without transactional guarantees.

Example of a problematic code segment:

try {
    int res1 = doStep1();
    this.status1 += res1;
    int res2 = doStep2();
    this.status2 += res2;
    // throw an exception
    int res3 = doStep3();
    this.status3 = status1 + status2 + res3;
} catch (...) {
    // ...
}

If an exception occurs in doStep3 , status3 is not updated while status1 and status2 may already have been changed, violating invariants and leaving data inconsistent.

Another difficult scenario involves a controller delegating to a service layer that assumes no exceptions will be thrown:

void controllerMethod(...) {
    try {
        return svc.doWorkAndGetResult(...);
    } catch (Exception e) {
        return ErrorJsonObject.of(e);
    }
}

void doWorkAndGetResult(...) {
    int res1 = otherSvc1.doStep1(...);
    this.status1 += res1;
    int res2 = otherSvc2.doStep2(...);
    this.status2 += res2;
    int res3 = otherSvc3.doStep3(...);
    this.status3 = status1 + status2 + res3;
    return SomeResult.of(this.status1, this.status2, this.status3);
}

Assuming the service layer need not handle exceptions is unsafe; any failure in doStep1 , doStep2 , or doStep3 can leave the service in an inconsistent state.

The recommended approach separates each step into its own try‑catch block with explicit rollback logic:

void doWorkAndGetResult(...) {
    int res1, res2, res3;
    try {
        res1 = otherSvc1.doStep1(...);
        this.status1 += res1;
    } catch (Exception e) {
        throw e;
    }

    try {
        res2 = otherSvc2.doStep2(...);
        this.status2 += res2;
    } catch (Exception e) {
        // rollback status1
        this.status1 -= res1;
        throw e;
    }

    try {
        res3 = otherSvc3.doStep3(...);
        this.status3 = status1 + status2 + res3;
    } catch (Exception e) {
        // rollback status1 and status2
        this.status1 -= res1;
        this.status2 -= res2;
        throw e;
    }
}

This pattern guarantees data consistency regardless of where an exception occurs, even though the code appears verbose compared to languages with simpler error handling.

The article concludes by urging developers to treat error handling with reverence, avoid relying on unchecked exceptions, and write unit tests to protect fragile correctness.