[Kotlin 세미나] 실패/예외 대응 방식

1. 디폴트 값으로 대처 

interface Transfer {
    fun moveTo(id : String)
}

interface Asset{
    val id: String
    val name: String
    val data: String
}

class Token(
    override val id: String,
    override val name: String,
    override val data: String) : Asset,Transfer{
    override fun moveTo(id: String) {
        TODO("Not yet implemented")
    }

}
class NFT(
    override val id: String,
    override val name: String,
    override val data: String) : Asset,Transfer {
    override fun moveTo(id: String) {
        TODO("Not yet implemented")
    }

}

class Account(val id: String, val name: String?): Transfer {
    val assets = mutableListOf<Asset>()
    override fun moveTo(id: String) {
        TODO("Not yet implemented")
    }
}

먼저 이런 코드가 있다고 가정 해 본다.

@Test
fun setUp() {
    val account = Account("1", null)
    val name = account.name?:"default_name"
    Assertions.assertEquals("default_name", name )
}

해당 Account의 name을 가져왔을 때 만약 null이라면 "default_name"을 넣어 줄 수 있다.
많은 경우 이렇게 처리 할 수 있을 것이다. 특히 설정값을 처리할 때 많이 사용되는데 특별히 설정된 값이 없을 경우 디폴트 값을 넣어주는 경우가 그럴 것이며 굉장히 처리하기 쉬운 경우이다.

2. nullable  

그리고 위에 보듯이 특정 값이 없을 경우 우리는 null을 리턴 할 수 있다.  비교적 일상적으로 벌어지는 문제이다.
즉 어떤 컬렉션에 특정 값이 없을 경우엔 null을 리턴하는게 정상이며 이후에 어떻게 처리 할 지는 사용자의 몫이다.

class Bank{
    val accounts = mutableMapOf<String, Account>()
    fun createAccount(account: Account){
        accounts.put(account.id, account)
    }
    
    fun getAccount(id: String): Account? {
        return accounts.get(id) 
    }
}

위에서 getAccount를 호출할 경우 해당 정보가 없을 수 도 있는데, 이것은 예외라고 보긴 어려울 것이다. (기술적으로 예외로 처리할 수도 있지만, 나는 그렇게 처리하지 않는다. 이유가 너무 명확하기 때문이다.) 

 @Test
 fun getAccount() {
   val bank = Bank()
   bank.createAccount(Account("1", "hama"))
   val result = bank.getAccount("1")?.name

  Assertions.assertEquals("hama", result)
}

만약 "2"를 넣어서  null을 리턴한다면 아무것도 처리하지 않으며, "1"을 넣는다면 name을 출력 할 것이다.  
? 는 null이 아닐 경우만 처리하라는 의미로, 위의 코드에서 ? 없이 name을 코딩 할 순 없다.
근데 위의 코드는 result에 null이 담길 수 있으므로 위험 할 수 있다. ?: 엘비스 연산자로 디폴트값을 넣거나 예외를 전파하거나 무엇인가 해야한다. NPE를 막아주는게 아니라 주의를 줄 뿐이다.

 val bank = Bank()
    bank.createAccount(Account("1", "hama"))
    bank.getAccount("1")?.let {
        val result = it.name
        println(result)
    }

적어도 let을 사용해 이렇게 하면 null을 전파하진 않는다.

3. Execption으로 전파 

null로 처리하게 된 다면, 호출당한 함수내부에서 어떤 이유로 null이 리턴 됬는지 궁금 할 수가 있다.일반적으로 예상되는 경우라면 호출한 측에서 이유를 작성 할 수도 있지만,  즉 예외가 왜 일어 났는지 잘 모를 수 있는 경우라면 호출당한 함수에서 이유를 알려주는 것이 일반적이다. 

class Bank{
    val accounts = mutableMapOf<String, Account>()
    fun createAccount(account: Account){
        accounts.put(account.id, account)
    }
    fun getAccount(id: String): Account? {
        return accounts.get(id)
    }

    fun dipositToken(accountId: String, token: Token){
        accounts.get(accountId)?.dipositToken(token)
    }

만약 위의 dipositToken을 호출했는데 accountId에 해당하는 계좌가 없으면 아무일도 안 일어날 것이다. 뭐 이렇게 되도 상관없을 수도 있겠다. 일관성이 깨지는 것 같은 큰 문제는 일어나지 않았으니깐, 대신 이 함수를 호출한 측에서는 diposit이 잘 됬는지 아닌지 알수가 없다. 잘 됬다고 생각하고 다음 단계를 밟을 수도 있는데 그렇게 되면 문제가 된다. 따라서 이 경우에는 리턴 값으로 문제 상황을 알리거나 예외를 전파해야하는데, 예외로 전파하는것을 추천한다. 나는 command 행동에서 문제가 생기면 예외를 던지고, query행동에서문제가 생기면 null (일반적인 상황일때) 혹은 예외(진짜 예외상황일때)를 전파하는 컨벤션을 갖는다.

@Throws(NoAccountException::class)
fun createToken(accountId: String, token: Token){
    accounts.get(accountId)?.createToken(token) ?: throw NoAccountException("there is no $accountId in our bank")
}

이렇게 예외를 던저주고 함수에 명시해 둔다. (호출하는 클라이언트에 대한 배려) 

@Test
fun dipositToken() {
    Assertions.assertThrows(NoAccountException::class.java, {
        bank.createToken("2", exception.Token("token_1", "opusm", 1000))
    })
}

Junit5를 통해서 테스트를 성공한다. 

 

4. Result 

1.5 버전 부터 Result<T> 을 사용 할 수 있다. 함수안에서 일어나는 일의 결과를 성공,실패로 단순히 알 수있는 Boolean과 다른점은 성공 했을 경우의 타입과 실패했을 경우의 예외 타입 및 메세지를 포함 시켜서 보다 풍부한 결과를 알고 싶을 때 사용한다. Result<T>구현은 유틸리티성 메소드가 굉장히 많이 포함되어 있다. 5번의 runCatching에서 더 설명한다.

import java.lang.IllegalArgumentException


data class Passport (val name: String, val age: Int)
data class EntranceData(val purposeCode: Int, val jobCode : Int, val passport: Passport)

data class PassportException(override val message: String?) : IllegalArgumentException(message)
data class JobException(override val message: String?) : IllegalArgumentException(message)


enum class Nation(val exportValid : List<ExportCheck>, val importValid : List<ImportCheck>) {
    KOREA(listOf(ExportCheck.Passport, ExportCheck.Job),listOf(ImportCheck.Passport) ),
    JAPAN(listOf(ExportCheck.Passport),listOf(ImportCheck.Passport)),
    USA(listOf(ExportCheck.Passport),listOf(ImportCheck.Passport));

    enum class ExportCheck {
        Passport {
            override fun check(data : EntranceData) : Result<String> {
                return if(data.passport.age > 10){
                    Result.success("Export passport ok")
                }
                else {
                    Result.failure(PassportException("reason why ~~"))
                }
            }
        },
        Job {
            override fun check(data : EntranceData) : Result<String>{
                return if(data.jobCode == 1){
                    Result.success("Export Job ok")
                }
                else {
                    Result.failure(JobException("reason why ~~"))
                }
            }
        };

        abstract fun check(data : EntranceData): Result<String>
    }

    enum class ImportCheck {
        Passport {
            override fun check(data : EntranceData) : Result<String>{
                return if(data.passport.age > 10){
                    Result.success("Export passport ok")
                }
                else {
                    Result.failure(PassportException("reason why ~~"))
                }
            }
        },
        Job {
            override fun check(data : EntranceData) : Result<String>{
                return if(data.jobCode > 1){
                    Result.success("Export Job ok")
                }
                else {
                    Result.failure(JobException("reason why ~~"))
                }
            }
        };

        abstract fun check(data : EntranceData): Result<String>
    }

    companion object {
        fun getNumberOfNations() = values().size
    }
}

fun tradeTest(entranceData: EntranceData, nation: Nation): List<Result<String>> {
  return nation.exportValid.map{
       it.check)
   }
}

fun main(args: Array<String>) {

    val korea = Nation.KOREA;
    val data = EntranceData(1,1, Passport("john",3))

    val results = tradeTest(data,korea)

    results.forEach { result ->
        result.onSuccess {
            println(it)
        }
        .onFailure {
            println(it.message)
        }
    }

}

5. runCatching 

runCatching은 Result<T>를 사용하는데 도움이 될 수 있다.

account)

fun withrawToken(id: String, balance: Int): Int {
    val token = assets.find { it -> it.id == id  } as Token
    require(token.balance > balance )
    token.balance = token.balance - balance
    return balance
}

bank)

fun withrawToken(accountId: String, tokenId: String, balance: Int): Int{
    val result = kotlin.runCatching {
        accounts.get(accountId)?.withrawToken(tokenId, balance)
    }

    return result.getOrDefault(0)!!
}

test)

@Test
fun withrawToken() {
    bank.createToken("1", exception.Token("token_1", "opusm", 1000))
    val result = bank.withrawToken("1", "token_1", 5000)
    Assertions.assertEquals(0, result)
}

아래와 같이 runCatching 문은 좀 더 다양한 방식으로 처리 될 수 있다. 

fun withrawToken(accountId: String, tokenId: String, balance: Int):String{
    return  kotlin.runCatching { accounts.get(accountId)?.withrawToken(tokenId, balance)}
    .onFailure { println(" withraw token failure") } // 특정 예외를 구분 할 수도 있다.
    .onSuccess { println(" withraw token success") }
    .mapCatching { it -> it.toString() }
    .getOrDefault("0") // getOrNull, getOrThrows
}

/////// 아래와 같이 특정 예외별로 구분해서 처리 할 수도 있다.
getOrElse {
    when(it) {
        is LowBalanceException -> "LowBalanceException"
        is IllegalStateException -> "IllegalStateException"
        is NullPointerException -> "null"
        else -> throw it
    }
}

 

전체 코드)

package exception

import exception.bankexception.LowBalanceException
import exception.bankexception.NoAccountException
import kotlin.jvm.Throws


interface Transfer {
    fun moveTo(id : String)
}

interface Asset{
    val id: String
    val name: String
}

enum class AssetKind{
    Token,
    NFT
}

data class Token(
    override val id: String,
    override val name: String,
    var balance: Int) : Asset,Transfer{
    override fun moveTo(id: String) {
        TODO("Not yet implemented")
    }

}
data class NFT(
    override val id: String,
    override val name: String) : Asset,Transfer {
    override fun moveTo(id: String) {
        TODO("Not yet implemented")
    }

}

data class Account(val id: String, val name: String?): Transfer {
    val assets = mutableListOf<Asset>()
    override fun moveTo(id: String) {
        TODO("Not yet implemented")
    }

    fun createToken(token: Token) {
        assets.add(token)
    }

    fun withrawToken(id: String, balance: Int): Int {
        val token = assets.find { it -> it.id == id  } as Token
        require(token.balance > balance )
        token.balance = token.balance - balance
        return balance
    }
}

class Bank{
    val accounts = mutableMapOf<String, Account>()
    fun createAccount(account: Account){
        accounts.put(account.id, account)
    }
    fun getAccount(id: String): Account? {
        return accounts.get(id)
    }

    @Throws(NoAccountException::class)
    fun createToken(accountId: String, token: Token){
        accounts.get(accountId)?.createToken(token) ?: throw NoAccountException("there is no $accountId in our bank")
    }

    fun withrawToken(accountId: String, tokenId: String, balance: Int):Int{
        return  kotlin.runCatching { accounts.get(accountId)?.withrawToken(tokenId, balance)}
        .onFailure { println(" withraw token failure") }
        .onSuccess { println(" withraw token success") }
        .getOrDefault(0)!!
    }
}

 

---

자바와 체크 예외 

- 어떤 예외에 대해 명시적으로 메서드 시그니처에 포함시켜서 좀 더 처리를 강제한다.
- 체크드예외는 클래스 못찾는거, 파일 못찾는거 IO예외, SQL예외 같은거...즉 언제든지 자신의 탓이 아닌데도 문제가 발생할 수 있고, 메모리가 없는것처럼 아예손놓고 있지 않아도 될 만한것
- 오류Error는 메모리나 HDD가 없는 것 처럼 멀 할 수 없는 경우를 말한다. 그냥 끝내는게 최선
- 런타임예외는 Error긴 한데 좀 다른 유행이다. 근데 런타임예외는 체크드예외인 Exception 아래에 있다.의도는 개발자의 실수에 의한 예외를 말한다. 널문제, 잘못된인자나 프로그램 상태 같은거. 즉 개발자의 탓이고 멍청하게 프로그램을 사용했으니 그냥 연산 중단 되버려지만 Error처럼 무조건 끝내지 말고복구를 시도 해 볼 순 있다 정도
- 문자열에서 데이터추출시 URL은 체크예외인 MalformedURLExcetion 던지지만
  Integer.parseInt 는 언체크예외인 NumberFormatException 던짐. ???
- 자바 8 람다나 함수형 인터페이스는 체크예외를 전파할 수 없게 됨. 개발자들 체크예외 사용 포기
- 그냥 모두 RuntimeException으로 다루자. (코틀린)

자바의 Optional

1. 자바 8이전에는 예외를 던지거나 null을 반환하는 것
2. 두 방법 모두 허점이 있는데 예외는 진짜 예외적인 상황(?)에서 사용해야 하며, 예외를 생성할 때 스택트레이싱 전체를 캡쳐하므로 비용도 많이 든다. null을 반환하면 이런 문제는 없지만 그것을 처리 안하면 원래 오류가 아니라 그냥 어디선가 갑자기 NullPointerException이 튀어 나올 수 있다.
3. Optional은 예외를 반드시 사용할 필요 없는 곳에 null대신 사용하기 좋다.
4. illegalArgumentException을 던지는 곳에 Optional을 던지는게 더 나은 경우가 많다. Optional은 검사를 강제하므로 검사예외와도 비슷한데 더 간단하고 함수형 처럼 체이닝 하기도 좋다.
6. 다만 컬렉션,스트림,배열,옵셔널 같은 컨테이너 타입은 옵셔널로 감싸면 안된다.
7. 물론 그냥 null을 던지는게 성능상은 더 유리하다.