검사 예외의 불편 검사 예외를 싫어하는 개발자가 많지만 제대로 활용하면 API와 프로그램의 질을 높일 수 있다. 반면 사용이 과해지면 불편하기만 할 수도 있다. 검사 예외가 단 하나뿐이라면 오직 그 예외 때문에 API 사용자는 try 블록을 추가해야 하고 스트림에서 직접 사용하지 못하게 된다. 그러니 이런 상황이라면 검사 예외를 안 던지는 방법이 없는지 고민해볼 가치가 있다. 검사 예외 회피 방법 비검사 예외 API를 제대로 사용해도 발생할 수 있는 예외이거나, 프로그래머가 의미 있는 조치를 취할 수 있는 경우라면 이 정도 부담쯤은 받아들일 수 있을 것이다. 하지만 이 경우들이 아니라면, 비검사 예외를 사용하는 것이 좋다. Optional 검사 예외를 회피하는 두 번째 방법은 적절한 결과 타입을 담은 옵..
검사 예외와 런타임 예외 자바는 문제 상황을 알리는 타입(Throwable)으로 검사 예외, 런타임 예외, 에러 이렇게 세 가지를 제공한다. 하지만, 해당 타입을 언제 무엇을 사용해야하는 지 헷갈리는 경우가 있다. 참고 지침 호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용하라. 검사 예외를 던지면 호출자가 그 예외를 catch로 잡아 처리하거나 더 바깥으로 전파하도록 강제하게 된다. 따라서, 메소드 선언에 포함된 검사 예외 각각은 그 메소드를 호출했을 때 발생할 수 있는 유력한 결과임을 API 사용자에게 알려주는 것이다. 비검사 throwable은 두 가지로, 런타임 예외와 에러이다. 이 둘은 프로그램에서 잡을 필요가 없거나 혹은 통상적으로 잡지 말아야 한다. 프로그램에서 비검사 예외나 ..
예외는 오직 예외 상황에서만 써야한다. 절대 일상적인 제어 흐름용으로 사용해선 안 된다. try { int i = 0; while(true) range[i++].climb(); } catch (ArraylndexOutOfBoundsException e) { } //표준적인 관용구 for (Mountain m : range) m.climb(); 잘못된 추론 예외를 통한 명확한 검사가 빠를 것이다. 코드를 try-catch 블록 안에 넣으면 JVM이 적용할 수 있는 최적화가 제한된다. JVM은 배열에 접근할 때마다 경계를 넘지않는지 매번 검사하므로. 이 부분을 제한한다는 추론으로 보인다. 배열을 순회하는 표준 관용구 는 JVM이 알아서 최적화해 중복 검사를 진행하지 않는다. 여기서 말한 중복검사는 JVM에서..
- Today
- Yesterday
- jvm
- 메인보드#asrock b650m #조립pc #후기이벤트
- Effective JAVA
- Concurrecy
- reactive
- gslb
- Serializable
- 영속성
- iterable
- template
- Redis
- Observer Pattern
- 디자인패턴
- in-memory
- Design Pattern
- 부하테스트
- template method
- strategy
- JMeter
- LAMBDA
- concurrency
- jdk11
- nosql
- exception
- Java
- Spring
- reactive stream
- observable
- Serialize
- object
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |