본문 바로가기
개발 노트/기초 지식

[java] try - catch, throw, throws, throw의 사용 이유

by tokkiC 2022. 5. 9.

논리의 공백으로 인해 exception 이 발생할 때 if else 문으로 논리를 추가하여 문제의 경우를 해결할수도 있지만

자바에서는 try - catch 문을 사용하도록 해서 예외의 해결을 지원한다

둘 다 예외를 해결할수있는데 어떤 때 뭘써야 할까? 일단 try catch 문을 알아보자


try catch


try {
예외 발생 가능성 있는 코드   //  예외 발생 여부 상관없이 실행됨. 예외 코드 아래의 코드는 실행되지 않고 catch 로 넘어간다
} catch (예외클래스1 e1) {         //  예외클래스 : exception, IO Exception 등등 / e 대신 다른 변수명도 가능 
예외1 발생 시에만 실행할 코드    //  예외 시 실행하거나 해결할 코드를 넣던가 예외의 정보를 출력하는 메소드를 넣는다
} catch (예외클래스2 e2) {                //  여러 경우의 예외가 예상되는 경우 이렇게 catch 를 중첩으로 사용하면 
예외2 발생 시에만 실행할 코드             //  해당 예외 발생 시 그에 맞게 처리할수있다
}                                 

try catch 구문에서 예외를 처리할수 있지만 해당 구문을 호출하는 변수나 메소드로 throws 던져서 처리를 미룰수있다

throw 로 예외를 처리하지 않고 넘긴 해당 try catch 구문을 사용하는 변수나 메소드를 참조하여(호출하여) 사용시에는

해결 못한 예외가 다시 뜨게 된다. 그럴때 다시 try catch 를 해서 예외를 받아 처리할수도 있다.

물론 다음 참조 시 해결하도록 다시 throws 로 미룰수 있지만 호출자 중 한 곳에서는 반드시 catch 를 해야만 할것이다


throw / throws


throw 는 개발자가 일부러 예외를 만들때 쓰는 키워드이며 명사형에서 볼수있듯 던질 것을 정의할때 쓰인다

// throw 의 사용 //

리턴타입 메소드명(매개변수1, ...) throws 예외클래스1, 예외클래스2, ... {
예외가 발생할 수 있는 코드
}

throws 는 동사형으로 알수있듯 던질게! 하고 자신을 호출한 상위 메소드로 예외 처리를 넘길때 쓰인다

메소드 선언부 뒤에 붙여서 쓴다

예외를 해당 메소드를 호출한 상위 메소드로 던지지만 거기서도 예외처리 하지 않고 다음으로 던지는 것이 반복되어

최상위 메소드까지도 처리 안하면 당연히 문제를 해결하지 않아서 프로그램에 예외가 뜨니 언젠가는 처리해야만한다

// throws 의 사용 //

예외를 발생시킬 메소드 {
throw new 예외클래스      //  예외클래스("예외 시 띄울 메세지") 형태로 예외 시 뜨게할 메세지를 적을수도 있다
}

throw 를 사용해 예외를 넘기는 이유


그렇다면 왜 throw 를 쓸까? 그때그때 예외마다 try catch 로 처리하면 될텐데 왜 굳이 넘길까?

납득할 이유를 찾기까지 상당히 오래걸렸다. 다음의 예시로 설명하겠다

무역 회사에서 업무를 보는 말단 직원인 내가 일을 하던 도중에 거래처와 문제가 생겼다

그 문제를 내가 알아서 해결한다면 (바로 try catch 로 처리한다면) 될텐데

왜 굳이 내 선에서 해결하지 않고 나를 지휘하는 팀장에게로 문제를 보고해야 할까? 나는 신입이라 해결을 못해서?

단순히 해결을 못해 상사에게 throw 하는 거면 숙련된 개발자들은 throw 하지 않을텐데 왜 그들도 throw 를 사용할까?

직장에서 문제가 발생 시 상사에게 보고하는 것은 부하직원이 답을 몰라서가 아니다

그 문제의 해결 권한과 방식을 정할 권한이 없기 때문이다 사내 규칙으로 그러기로 정했으니까!

내가 throw 한 예외를 팀장은 사장에게 보고하게되어 예외 처리를 사장(최상위 핸들러)이 결정하게 된다

각 예외들이 처리까지 여러 명의 직원의(여러 하위메소드의) 손을 타지 않고 사장 한 명(최상위 핸들러) 이 처리하니

이 방법은 여러명이 작업할 시 혹은 모듈화 된 프로젝트를 작업할 시 각자가 같은 예외에 대해 다르게 처리하지 않고

한 예외에 대해 일관된 처리방법을 사용할 수 있고, 한 번에(한 명이) 처리하기 때문에 일관된 개념으로 처리할수 있다

각 예외의 처리 방법이 달라져도 하위 메소드로 하나하나 수정 방법을 전파하고 수정할 필요없이 한 번에 수정 가능하니

예외에 있어서 유지 관리 효율을 높일 수 있다

예외를 모으면 한 눈에 보기에도 좋으니 참고자료로 공동작업자들에게 예외의 처리 메뉴얼로서 사용도 가능할것이다

또한 처리권한을 하위 직원(하위 메소드)가 가지고 있지 않고 상사에게(상위 메소드로) 넘기기때문에

하위 직원들은 각자의 다른 방법으로 예외를 처리한다고 개인(각 메소드)마다 다른 방식들로 혼란스럽게 일하지 않고

예외를 throw 후 평소 업무에만 집중하여 사무실이 쾌적해질것이다 (코드의 보기 쉽게하고 각자의 기능에 집중가능)

물론 말단 직원이 처리권한이 있고 혼자서 모든 업무를 보고(작업자가 한 명이고)

작은 프로젝트라 굳이 예외를 따로 기록, 관리할 필요가 없다면 그냥 예외가 보이는대로 바로 catch 하여 처리해도 된다

한 명뿐인 직원에게 모든 문제처리 권한이 있는 작은 회사라면

굳이 사장에게 보고하지 않고 그 직원이 바로바로 처리하는것이 나을 수도 있을것이다 뭐 그런 말이다

이런 이유들로 인해서 예외를 throw 한다고 생각하면 될 것같다

+ 예외를 사용자가 정의해서 원하는 방식으로 처리할 수 있다는 장점도 있다

권한 없으면 throw 하라구 신삥!

댓글