티스토리 뷰
오류 처리
오류 코드보다 예외를 사용하라
- 오류를 코드로 처리하면 호출자 코드가 복잡해진다. 함수를 호출한 즉시 오류를 확인해야 하기 때문이다.
- 오류가 발생하면 예외를 던지는 편이 낫다. 호출자 코드가 더 깔끔해진다.
public void sendShutDown(){
try{
tryToShutDown();
}catch(DeviceShutDownError e){
logger.log(e);
}
}
예외를 던지고 코드를 분리함으로써 각 개념을 독립적으로 살펴보고 이해할 수 있다.
Try-Catch-Finally 문부터 작성하라
- try-catch-finally 문에서 try 블록에 들어가는 코드를 실행하면 어느 시점에서든 실행이 중단된 후 catch 블록으로 넘어갈 수 있다.
- try 블록에서 무슨 일이 생기든지 catch 블록은 프로그램 상태를 일관성 있게 유지해야 한다.
- 그러기 위해서 catch를 사용하는 것
public List<RecordedGrip> retrieveSection(String sectionName){
try{
FileInputStream stream = new FileInputStream(sectionName);
stream.close();
}catch(FileNotFoundException e){
throw new StorageException("retrieval error",e);
}
return new ArrayList<RecordedGrip>();
}
- 먼저 강제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 하는 코드를 작성하는 방법을 권장한다.
- 그러면 자연스럽게 try 블록의 트랜잭션 범위부터 구현하게 되므로 범위 내에서 트랜잭션 본질을 유지하기 쉬워진다.
미확인 예외를 사용하라
- 확인된 예외는 OCP(Open Closed Principle)를 위반한다.
- 메소드에서 예외를 던졌는데 catch 블록이 세 단계 위에 있다면 그 사이 메소드 모두가 예외를 정의해야 한다.
- 아주 중요한 라이브러리를 작성할 때를 제외하면 확인된 예외는 비용소모가 더 크다.
예외에 의미를 제공하라
- 예외를 던질 때는 오류가 발생한 원인과 위치를 찾기 쉽도록 전후 상황을 충분히 덧붙인다.
- 오류 메시지에 정보를 담아 예외와 함께 던진다.
호출자를 고려해 예외 클래스를 정의하라
- 오류가 발생한 컴포넌트로 분류한다. 유형으로도 분류가 가능하다.
- 호출하는 라이브러리 API를 감싸면서 예외 유형 하나를 반환하게 한다.
- 외부 API를 감싸면 외부 라이브러리와 프로그램 사이에서 의존성이 크게 줄어든다.
정상 흐름을 정의하라
- 예외가 발생하는 특수상황이 없도록 만들면 코드가 훨씬 더 간결해진다.
try{
MealExpenses expenses = expensesReportDAO.getMeals(employee.getID());
m_total += expenses.getTotal();
} catch(MealExpensesNotFound e){
m_total += getMealPerDiem();
}
위와같은 특수한 예외상황 자체가 안나오도록 만들어준다.
public class PerDiemMealExpenses implements MealExpenses{
public int getTotal(){
//기본값으로 일일기본 식비를 반환한다.
}
}
클래스나 객체가 예외적인 상황을 캡슐화해서 상황을 처리하므로 클라이언트 코드가 예외적인 상황을 처리할 필요가 없어진다. 이를 특수 사례 패턴이라 부른다.
null을 반환하지 마라
- null을 반환하는 코드는 일거리를 늘릴 뿐만 아니라 호출자에게 문제를 떠넘긴다. 누구 하나라도 null 확인을 빼먹는다면 애플리케이션이 통제 불능에 빠질지도 모른다.
- null을 반환하는 대신 예외를 던지거나 특수 사례 객체를 반환한다.
- 자바에는 Collections.empltyList()가 있어 미리 정의된 읽기 전용 리스트를 반환한다.
public List<Employee> getEmployees(){
if( ... )
return Collections.emptyList();
}
null을 전달하지 마라
- null을 인수 값으로 전달하는 방식도 피해야 한다.
- 인수 값으로 null을 전달하면 결국 메소드위치에서 null을 검사하는 처리가 필요하다.
경계
외부 코드 사용하기
- 예) java.util.map
- Map은 굉장히 다양한 인터페이스로 수많은 기능을 제공한다.
- Map이 제공하는 기능성과 유연성은 확실히 유용하지만 그만큼 위험도 크다.
- 경계 인터페이스인 Map을 Class 안으로 숨기면, Map 인터페이스가 변하더라도 나머지 프로그램에는 영향을 미치지 않는다.
public class Sensors{
private Map sensors = new HashMap();
public Sensor getById(String id){
return (Sensor) sensors.get(id);
}
}
- Map과 같은 경계 인터페이스를 이용할 때는 이를 이용하는 클래스나 클래스 계열 밖으로 노출되지 않도록 주의한다.
경계 살피고 익히기
- 우리쪽 코드를 작성해 외부 코드를 호출하는 대신 먼저 간단한 테스트 케이스를 작성해 외부 코드를 익히자.
log4j 익히기
- 학습 테스트
- 프로그램에서 사용하려는 방식대로 외부 API를 호출
- 실제 코드와 동일한 방식으로 인터페이스를 사용하는 테스트 케이스가 필요하다.
- 이런 경계 테스트가 있다면 패키지의 새 버전으로 이전하기 쉬워진다.
깨끗한 경계
- 경계에 위치하는 코드는 깔끔히 분리한다.
- 또한 기대치를 정의하는 테스트 케이스도 작성한다.
- 외부 패키지를 호출하는 코드를 가능한 줄여 경계를 관리하자.
- Map에서 봤듯이, 새로운 클래스로 경계를 감싸거나 아니면 ADAPTER 패턴을 사용해 우리가 원하는 인터페이스를 패키지가 제공하는 인터페이스로 변환하자
'Book > Clean Code' 카테고리의 다른 글
[Clean Code] 시스템 (0) | 2022.01.26 |
---|---|
[Clean Code] 클래스 (0) | 2022.01.25 |
[Clean Code] 형식 맞추기, 객체와 자료구조 (0) | 2022.01.23 |
[Clean Code] 주석 (0) | 2022.01.18 |
[Clean Code] 깨끗한 코드, 의미있는 이름, 함수 (0) | 2022.01.18 |
댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
- Total
- Today
- Yesterday
링크
TAG
- 백준
- 리팩토링
- 데이터베이스
- leetcode
- webflux
- 자료구조
- 코틀린
- MySQL
- kotlin
- 인프런
- 북클럽
- 코테
- 파이썬
- 노마드코더
- 릿코드
- 노마드
- 스프링 부트
- Algorithm
- 그리디
- 정렬
- 스프링부트
- 구현
- mysql 8.0
- Spring
- spring boot
- 문자열
- 김영한
- 알고리즘
- 스프링
- Real MySQL
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
글 보관함