[Android] Http 에러

💡네트워크 요청 중에 발생할 수 있는 에러에 대해 알아보고, 해결 방안을 기록하였습니다.

 

HTTP

• Android에서 HTTP 에러는 주로 네트워크 요청 중에 발생하며, 이는 서버 간의 통신이 실패하거나 서버가 요청을 처리하지 못할 때 나타냅니다.
• 이는 HTTP 상태 코드, 네트워크 연결 문제, 서버의 응답 처리 오류 등의 이유가 있을 수 있습니다.
• 아래와 같은 일반적인 오류로 분류할 수 있고, JSON 파싱이나 SSL 인증서 오류도 발생할 수 있습니다.

4XX

• HTTP 상태 코드 4XX를 가지면 클라이언트 오류로 분류합니다.
• 400 : Bad Resquest
• 401 : Unauthorized
• 403 : Forbidden
• 404 : Not Found

5XX

• HTTP 상태 코드 5XX를 가지면 서버 오류로 분류합니다.
• 500 : Internal Server Error
• 502 : Bad Getway
• 503 : Service Unabilable
• 504 : Getway Timeout

네트워크 오류

• 네트워크 연결이 불안정하거나, Wi-Fi 또는 모바일 데이터가 끊겼을 때 네트워크 연결 실패 에러가 발생합니다.
• 서버가 일정 시간 내에 응답하지 않으면 타임 아웃이 발생합니다.

부적절한 예외처리

• 안드로이드에서는 HTTP 요청을 할 때 주로 Retrofit이나 OKHttp와 같은 라이브러리를 사용합니다.
• 이러한 라이브러리를 통해 HTTP 요청 및 에러를 처리할 수 있습니다.
• view와 데이터를 연결하는 ViewModel에서 아래와 같이 에러 처리를 진행할 수 있습니다.

// Retrofit API Interface
interface ApiService {
    @GET("example/data")
    suspend fun getData(): Response<Data>
}

// ViewModel
class MyViewModel(private val apiService: ApiService) : ViewModel() {

    fun fetchData() {
        viewModelScope.launch {
            try {
                val response = apiService.getData()
                if (response.isSuccessful) {
                    // 성공적으로 데이터를 받은 경우
                    val data = response.body()
                    // 처리 로직
                } else {
                    // HTTP 에러 처리
                    handleHttpError(response.code())
                }
            } catch (e: Exception) {
                // 네트워크 오류 또는 기타 예외 처리
                handleNetworkError(e)
            }
        }
    }

    private fun handleHttpError(code: Int) {
        when (code) {
            400 -> Log.e("Error", "Bad Request")
            401 -> Log.e("Error", "Unauthorized")
            404 -> Log.e("Error", "Not Found")
            500 -> Log.e("Error", "Internal Server Error")
            else -> Log.e("Error", "Unknown HTTP Error: $code")
        }
    }

    private fun handleNetworkError(e: Exception) {
        if (e is SocketTimeoutException) {
            Log.e("Error", "Request Timeout")
        } else if (e is UnknownHostException) {
            Log.e("Error", "No Internet Connection")
        } else {
            Log.e("Error", "Unknown Network Error: ${e.message}")
        }
    }
}

• 이는 상태 코드와 네트워크, 타임아웃에 대한 에러를 분기처리한 모습이지만, 아래와 같은 문제가 발생합니다.

서버 응답 코드를 ViewModel에 전파

위 코드는 서버 응답 코드를 ViewModel에서 알고 있습니다. ViewModel은 아키텍처에서 UI와 데이터 사이의 중재자 역할을 수행합니다. 따라서 ViewModel이 서버 응답 코드나 데이터 출처에 대해 아는 것은 바람직하지 않으며, ViewModel은 데이터가 어디서 오는지 상관없이 UI를 업데이트하는 역할에 집중해야 합니다.

관심사 분리

• ViewModel은 UI의 상태를 관리하고, 데이터가 UI에 어떻게 표시될지를 결정하는 역할을 해야 합니다.
• 서버, 로컬 데이터베이스 등의 데이터 출처와 응답코드는 Repository나 DataSource 계층에서 관리해야 하며, ViewModel은 데이터의 출처와 무관하게 필요한 데이터를 제공받아야 합니다.

비즈니스 로직이 ViewModel로 전파

만약 ViewModel이 서버 응답 코드를 알게 된다면, 이는 비즈니스 로직이 ViewModel에 포함되어 관심사의 분리가 무너질 수 있습니다. 특정 데이터 출처에 종속적이 되어, 테스트하기 어렵고 코드가 복잡해질 수 있습니다.

Result 객체 활용

Result 객체?

• Result 객체는 데이터의 처리 결과를 성공과 실패로 나누어 표현화는 표준화된 데이터 래퍼입니다.
• 이를 활용해서 함수나 메서드가 성공적인 결과와 실패 상황을 명확하게 구분하고, 이를 하나의 반환 값으로 처리할 수 있습니다.

sealed class Result<out T> {
    data class Success<out T>(val data: T) : Result<T>()
    data class Error(val exception: Throwable) : Result<Nothing>()
}

• Kotlin에서는 기본적으로 Kotlin.Result를 제공하지만, 이를 커스텀하여 더욱 유연하게 활용할 수 있습니다.

세분화된 Result 객체

• Result 객체를 에러 처리에 적합하게 활용하기 위해서 세분화할 수 있습니다.

sealed class Result<out T> {
    data class Success<out T>(val data: T) : Result<T>()
    data class HttpError(val statusCode: Int) : Result<Nothing>() // HTTP 상태 코드 에러
    data class NetworkError(val exception: Throwable) : Result<Nothing>() // 네트워크 에러 (타임아웃, 연결 실패 등)
}

• 이를 활용하면 HTTP 상태 코드, 네트워크 오류, 타임아웃에 맞게 세분화할 수 있으며, 구체적인 에러 처리가 가능합니다.

Repository에서 에러 처리

• Repository에서 에러처리를 진행하여 비즈니스 로직이 ViewModel로 전파되는 것을 방지할 수 있습니다.
• ViewModel로 Result로 감싸진 객체를 전달하여 ViewModel에서는 에러 코드를 알 수 없게 할 수 있습니다.

class DataRepository(private val apiService: ApiService) {
    
    suspend fun getData(): Result<List<String>> {
        return try {
            val response = apiService.getData() // 서버에 데이터 요청
            if (response.isSuccessful) {
                Result.Success(response.body() ?: emptyList())
            } else {
                Result.HttpError(response.code()) // HTTP 상태 코드 에러 처리
            }
        } catch (e: IOException) {
            // 네트워크 예외 처리 (네트워크 연결 실패, 타임아웃 등)
            Result.NetworkError(e)
        }
    }
}

UI로 전파

• 감싸진 Result객체를 분석하여 사용자에게 다른 UI를 보여줄 수 있습니다.

// ViewModel에서 데이터를 가져오고 Result에 따라 분기 처리
class MyViewModel(private val repository: DataRepository) : ViewModel() {
    private val _uiState = MutableLiveData<Result<List<String>>>()
    val uiState: LiveData<Result<List<String>>> get() = _uiState

    fun loadData() {
        viewModelScope.launch {
            _uiState.value = Result.Loading
            val result = repository.getData()
            _uiState.value = result // 네트워크 에러, 상태 코드 등을 처리한 Result 반환
        }
    }
}

// UI에서 Result 객체의 상태에 따라 UI 갱신
@Composable
fun MyScreen(viewModel: MyViewModel = hiltViewModel()) {
    val uiState by viewModel.uiState.observeAsState(Result.Loading)

    when (uiState) {
        is Result.Success -> ShowData((uiState as Result.Success).data) // 성공 시 데이터 렌더링
        is Result.HttpError -> ShowError("HTTP Error: ${(uiState as Result.HttpError).statusCode}") // HTTP 상태 코드 처리
        is Result.NetworkError -> ShowError("Network Error: ${(uiState as Result.NetworkError).exception.message}") // 네트워크 에러 처리
    }
}

이런 과정이 필요한 이유는?

분리된 에러 처리

• ViewModel은 단순히 UI 상태를 관리하고, 세부적인 네트워크 및 HTTP 상태 코드에 대한 처리는 Repository로 분리됩니다.
• 이는 유지보수를 용이하게 하고, 코드의 관심사 분리를 유지하는 데 도움을 줍니다.

테스트 용이성

• 각 상태를 분리함으로써 개별적인 테스트가 가능합니다.
• 성공 응답, HTTP 상태 에러, 네트워크 에러를 각각 테스트할 수 있습니다.

사용자 경험 향상

• 다양한 에러 상황에 따라 적절한 메시지나 UI 피드백을 제공할 수 있습니다.
• 이는 사용자가 예상치 못한 상황을 방지하며, 친절한 예외 전달로 사용자 경험을 크게 향상시킬 수 있습니다.

Sandwich?

• 복잡한 애플리케이션 아키텍처에서 API 처리를 진행할 때, 매번 예외처리 코드를 작성하는 것은 많은 시간을 소모할 수 있습니다.
• Sandwich는 Multi-Layred 아키텍처에서 데이터 흐름과 Retrofit 응답 및 에러를 간결하고 명시적으로 다루는 라이브러리를 제공하고 있습니다.

https://github.com/skydoves/sandwich