에러 -> 프로그램이 ㅣ오작동 / 비정상 종료가 되게 하는 원인
종류 : 컴파일, 런타임, 논리적 오류
에러 : 코드상에서 해결할 수 없는 오류들
예외 : 코드상에서 해결할 수 있는 오류들
Exception vs Runtime Exception
Runtime Exception <= UnCheked Exception 컴파일이 가능
Exception <= Cheked Exception 컴파일이 불가능
자바에서의 예외처리는 사실 문제가 있다. throw로 예외를 인스턴스화해서 던진다라..
go에서 많이 공격 받는 부분이라고 한다.
스프링에서는 이를 AOP를 이용해서 해결한다.
AOP는 관전 지향 프로그래밍(관점 분리적인 맥락) <= (난 예외처리로 사용할 생각은 못해봤다)
에외를 처리할 때 우리는 호출한 부분에 에러를 줘야할까?
아니면 에러를 try catch문으로 해결하고 진행해야 할까?
고민해야할 부분이지만 에러가 발생하면 예측할 수 없는 값을 리턴해서 호출한 부분에서 else 로 처리하게 하거나 예외에 대한 공통된 클래스를 만들어서 해결하자는 약속을 하자.
이렇게 되면 @Advice를 활용해서 처리할 수 있다.
에러라는 것이 비지니스에서 벗어낫기 때문에 분리하는 것이다.(AOP)
예외처리방법
try catch문
throws
try with resource
try with resoure 는 java1.7 이후로 나온 기능으로
https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html 이부분을 참고하면 알 수 있다.
내용을 요약하자면 자바에서 사용후에 반납해야 하는 자원들 BufferedReader, FileReader, FileInputStream 등을 java1.7 이전에는
FileReader fr = new FileReader(path);
BufferedReader br = new BufferedReader(fr);
try {
return br.readLine();
} finally {
br.close();
fr.close();
}
이런식으로 작성했다고 한다.
프로그램은 리소스 작업이 완료된 후, 메모리를 회수하기 위해 Garbage Collection에 의존하는 것 이상의 작업을 수행해야한다. (예컨데 close를 하기 위해서 나타나느 예외를 처리한다거나 null인지 아닌지 체크하는 코드를 작성한다거나, 혹은 앞선 자원을 반납하는 과정에서 에러가 나타나 뒷 자원을 반납하지 못하는 점을 고려해야한다.)
그런데 이런 과정에서 코드의 indent가 늘어나면서 가독성이 떨어질 수 있다.
그래서 등장한게 try with resource이다. try with resource는 알아서 모든 자원을 반납해준다.
try (
java.util.zip.ZipFile zf =
new java.util.zip.ZipFile(zipFileName);
java.io.BufferedWriter writer =
java.nio.file.Files.newBufferedWriter(outputFilePath, charset)
) {
// Enumerate each entry
for (java.util.Enumeration entries =
zf.entries(); entries.hasMoreElements();) {
// Get the entry name and write it to the output file
String newLine = System.getProperty("line.separator");
String zipEntryName =
((java.util.zip.ZipEntry)entries.nextElement()).getName() +
newLine;
writer.write(zipEntryName, 0, zipEntryName.length());
}
사용방법은 try(이 부분에서 객체 생성) {비지니스 로직 수행} 이런 식이다.
장점으로 코드를 간결하게 만들 수 있고, 번거로운 자원을 반납하지 못하는 경우를 배제할 수 있다. 또 실수로 자원을 반납하지 못하는 경우를 방지할 수 있다.