Exercise 2: Adding a Specific .unauthorized APIError Case — Possible Solution
====================================================================================

// Updated APIError:
enum APIError: Error, LocalizedError {
    case invalidURL
    case requestFailed(statusCode: Int)
    case decodingFailed
    case unauthorized

    var errorDescription: String? {
        switch self {
        case .invalidURL:
            return "The request URL was invalid."
        case .requestFailed(let statusCode):
            return "The server returned status \(statusCode)."
        case .decodingFailed:
            return "The server's response couldn't be understood."
        case .unauthorized:
            return "Your session has expired. Please log in again."
        }
    }
}

// Updated fetch function:
struct APIClient {
    func fetch<T: Decodable>(_ type: T.Type, from url: URL) async throws -> T {
        let (data, response) = try await URLSession.shared.data(from: url)

        guard let httpResponse = response as? HTTPURLResponse else {
            throw APIError.requestFailed(statusCode: 0)
        }
        if httpResponse.statusCode == 401 {
            throw APIError.unauthorized
        }
        guard (200..<300).contains(httpResponse.statusCode) else {
            throw APIError.requestFailed(statusCode: httpResponse.statusCode)
        }

        do {
            return try JSONDecoder().decode(T.self, from: data)
        } catch {
            throw APIError.decodingFailed
        }
    }
}

HOW IT WORKS: A new real case, .unauthorized, is added to APIError,
with its own genuinely specific errorDescription message - one a
ViewModel could plausibly show directly to a user, or use as a signal
to redirect them to a login screen, rather than a generic
"server returned status 401" message that gives no real guidance on
what to actually do next.

The fetch function's own status-code check is reordered so the real
401 case is checked BEFORE the general 200..<300 success range check
- 401 sits outside that success range anyway, but checking it first
and explicitly means a 401 always throws the specific, meaningful
.unauthorized case rather than falling through into the generic
.requestFailed(statusCode: 401) the original, unmodified code would
have thrown instead.

ANSWER: Adding a case .unauthorized to APIError with its own specific,
user-facing errorDescription, and checking for status code 401
explicitly before the general 2xx success range check, correctly makes
a 401 response throw the specific .unauthorized error rather than the
generic .requestFailed(statusCode:) case.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly extends the real error enum with a new, specific case
and updates the checking logic so that specific real-world condition
(401) is caught and reported distinctly rather than folded into a
generic catch-all.