답변.

코틀린은 예외 처리(exception handling)를 자바와 유사하게 구현하지만 중요한 차이점이 있습니다. 코틀린에서는 익숙한 구조인 try, catch, 및 finally를 사용하지만, 근본적인 차이점은 코틀린에서는 checked exceptions가 없습니다. 즉, 모든 예외(런타임 오류)는 unchecked로 간주되며, 함수의 시그니처에 명시하지 않거나 명시적으로 잡을 필요가 없습니다.

주요 사항:

try/catch/finally 블록은 예외를 잡고 처리할 수 있게 해줍니다. finally 블록은 예외가 발생하더라도 항상 실행됩니다.
자바와의 차이점: 코틀린은 모든 예외를 unchecked로 처리합니다. 이것은 구문을 단순화하지만, 오류 처리를 더욱 신중하게 접근해야 합니다.
코틀린은 try 블록에서 "return value"를 지원하며, 즉 try를 표현식으로 사용하여 결과를 반환할 수 있습니다.
새로운 관용구: try/catch를 흐름 제어(flow control)로 사용하는 것을 피하는 것이 권장됩니다 — 진정한 예외 상황에서만 사용하세요.

fun parseIntOrNull(str: String): Int? = try {
    str.toInt()
} catch (e: NumberFormatException) {
    null
}

모범 사례:

논리 제어(flow control)에 사용하지 마세요.
use를 통해 자원 관리(resource management)를 사용하여 자동 닫기를 수행하세요(예: 파일).
빈 catch로 예외를 무시하지 마세요.

속은 질문.

코틀린에서는 함수 시그니처에 어떤 예외가 발생하는지 명시해야 하나요? (자바의 throws처럼)

올바른 답변: 아니요, 코틀린에는 checked exceptions 메커니즘이 없습니다. 모든 예외는 unchecked입니다. 함수 시그니처에 throws 구문이 존재하지 않습니다(예외 — @Throws 어노테이션은 자바와의 호환성을 위한 것, 오로지 interop용입니다).

이 주제에 대한 세부사항을 알지 못해 발생한 실제 오류의 예.

이야기

프로젝트에서 checked exceptions를 사용하는 자바 코드를 코틀린으로 마이그레이션 했습니다(예: IOException). 마이그레이션 후 개발자가 파일 작업 시 예외를 처리하는 것을 잊어서 — 실제 파일에서 애플리케이션이 충돌하기 시작했습니다, 왜냐하면 아무도 IO 오류를 처리하지 않았기 때문이며, 컴파일러가 자바처럼 경고할 것이라고 생각했기 때문입니다.

이야기

팀의 한 구성원이 흐름 제어(flow-control)용으로 try/catch를 잘못 사용하여 로그 파싱 속도를 저하시키고(유효하지 않은 각 문자열에 대해 NumberFormatException을 잡아서 — 대량의 데이터에서 성능이 급격히 저하됨).

이야기

JVM을 통해 코틀린에서 호출된 자바 코드가 checked exceptions(throws)를 선언했습니다. 코틀린 코드는 "모든 것이 unchecked"라고 생각하여 예외를 처리하지 않았고 — 결과적으로 치명적인 오류가 생산 환경 사고가 발생할 때까지 간과되었습니다.

코틀린에서 예외 처리(exception handling)는 어떻게 작동하나요? 세부사항, 자바와의 차이점, checked/unchecked 예외 처리, 'try', 'catch', 'finally', 전파 및 모범 사례를 설명하세요. 예제를 제시하세요.

답변.

주요 사항:

모범 사례:

속은 질문.

이 주제에 대한 세부사항을 알지 못해 발생한 실제 오류의 예.