예외 처리 (Exception Handling)

예외 처리(Exception Handling)는 실행 중 전달된 예외를 받아 복구하거나 상위 호출자로 넘기고, 필요한 정리를 수행하는 제어 방식입니다. 예외에는 실패 종류와 원인을 나타내는 정보가 담깁니다. 처리할 범위와 복구 가능성을 구분하며, 파일 닫기 같은 자원 정리는 작업의 성공 여부와 별도로 관리합니다.

예외의 발생과 호출 경로

파일이 없거나 요청한 형식으로 값을 바꿀 수 없으면 함수가 예외를 발생시킬 수 있습니다. 예외가 발생한 구간에서는 정상 실행이 중단되고 처리기를 찾는 흐름으로 옮겨갑니다. Python의 예외 처리 설명은 try 안에서 예외가 발생하면 남은 구문을 건너뛰고, 해당 종류를 받는 except가 있으면 실행한다고 설명합니다. 처리기가 맞지 않으면 바깥 호출 경로로 예외가 전달됩니다.

JavaScript의 try·catch, Python의 try·except처럼 문법 이름은 언어에 따라 다릅니다. MDN의 try...catch 문서는 try 안에서 호출한 함수가 던진 예외도 catch로 전달되는 흐름을 설명합니다. 실패를 일으킨 함수 바로 옆에서만 처리할 수 있는 것은 아닙니다. 어떤 계층이 복구에 필요한 정보를 갖고 있는지에 따라 처리 위치를 선택합니다.

예외 종류와 호출 기록은 디버깅에 필요한 단서입니다. 값을 숫자로 바꾸지 못한 오류와 네트워크 연결 실패는 조치가 다르므로 같은 성공값으로 바꿔 반환하면 호출자는 상황을 구별하기 어렵습니다. 다른 종류의 예외로 바꿔 전달할 때도 원래 원인을 연결할 수 있습니다. Python은 예외를 다시 발생시키거나 원인 예외를 연결하는 방법을 설명하며, 이런 정보가 어느 호출에서 문제가 시작됐는지 추적하는 데 쓰입니다.

복구 가능한 실패와 오류 누락

설정 파일이 없는 경우 기본 설정을 사용하도록 계약이 정해져 있다면 해당 실패를 처리하고 계속할 수 있습니다. 저장 실패 뒤에도 성공한 것처럼 다음 단계로 진행하면 실제 상태와 응답이 어긋납니다. .NET의 예외 처리 지침은 복구할 수 있을 때 예외를 잡고, 그렇지 않을 때는 호출 경로의 상위 계층이 처리하도록 설명합니다. 오류 메시지를 기록하는 것과 정상 상태로 복구하는 것은 다른 작업입니다.

예외를 지나치게 넓게 잡으면 예상한 입력 오류와 코드 결함이 같은 분기로 들어갑니다. 이때 빈 결과를 돌려주는 처리는 조회 결과가 실제로 없는 상황과 조회 자체가 실패한 상황을 섞습니다. 처리기는 어떤 예외를 받는지와 그 뒤의 상태를 함께 정의해야 합니다. 웹 요청의 가장 바깥 경계에서 실패를 응답으로 바꾸더라도 내부 원인 기록과 호출자에게 전달할 실패 표시가 필요합니다.

비동기 작업은 시작한 시점과 실패가 관찰되는 시점이 다를 수 있습니다. .NET 지침은 비동기 작업의 예외를 기다리는 지점에서 처리하는 경우를 설명합니다. 작업을 시작하는 호출만 감싸고 완료를 기다리지 않으면 이후의 실패가 그 처리 범위에 들어오지 않을 수 있습니다. 취소도 프레임워크에 따라 별도 예외로 나타나므로, 사용자가 중단한 작업과 서비스 장애를 구분할 필요가 있습니다.

자원 정리와 변경 상태 복원

파일이나 연결을 사용한 뒤에는 정상 종료와 실패 경로 모두에서 정리가 필요합니다. Python의 정리 동작 설명은 finally를 파일·연결 해제에 사용하며, 파일처럼 정리 동작을 갖춘 객체에는 with를 사용할 수 있다고 설명합니다. 자원을 해제하는 동작은 실패를 해결하는 동작과 구별됩니다. 파일을 닫았더라도 쓰기 작업이 끝나지 않았다면 호출자에게는 실패가 전달될 수 있습니다.

정리 구문에서 새 값을 반환하면 원래의 반환값이나 예외가 가려질 수 있습니다. MDN의 finally 설명은 finally 안의 제어 흐름이 앞서 발생한 결과를 덮는 경우를 경고합니다. 정리 코드가 또 다른 실패를 일으킨 경우에도 원래 실패가 어떻게 보존되는지 확인합니다. finally를 사용했다는 이유만으로 강제 프로세스 종료나 장비 장애까지 포함한 모든 상황의 자원 해제를 보장하지 않습니다.

예외를 잡아도 이미 끝난 변경이 자동으로 되돌아가지는 않습니다. .NET의 상태 복원 지침은 계좌 이체 중 입금이 실패했을 때 먼저 끝난 출금을 복원하는 사례를 다룹니다. 실제 시스템에서는 데이터베이스의 원자적 처리나 별도 보상 동작처럼 변경 방식에 맞는 설계가 필요합니다. 오류 처리 검증에서는 실패 응답뿐 아니라 남은 데이터와 해제되지 않은 자원도 살펴야 합니다.