Loading States, Errors, and Timeouts in Integrations

An internal Apex or LDS operation (Module 6, Module 7) fails in fairly predictable ways. An external HTTP callout adds genuinely new failure modes: the request can time out, the external system can return a non-2xx status code, or the external system can simply be down or unreachable — none of which is under this org's control at all.

public static WeatherSummary getCurrentWeather(String city) {
    try {
        HttpResponse response = new Http().send(buildRequest(city));

        if (response.getStatusCode() != 200) {
            throw new AuraHandledException('Weather service returned an unexpected response.');
        }

        WeatherResponse raw = (WeatherResponse) JSON.deserialize(response.getBody(), WeatherResponse.class);
        return new WeatherSummary(raw.temperature, raw.conditions);
    } catch (CalloutException e) {
        throw new AuraHandledException('Could not reach the weather service. Please try again.');
    }
}

Checking response.getStatusCode() explicitly — rather than assuming success — catches a non-2xx response. Wrapping the callout in try/catch for CalloutException catches network-level failures like timeouts. Both paths translate into a clear AuraHandledException message (Module 7), never a raw, leaked exception detail.

Module 8's loading-state pattern (disable the button, show a spinner, reset in finally) applies here too — but external calls are often meaningfully slower and less predictable than an internal call, making a visible loading state even more important. A user staring at an unresponsive button during a slow external callout, with no loading indicator at all, is a genuinely poor experience this pattern directly prevents.