티스토리 뷰
개발을 진행하다 보면 Exception 정보의 중요성을 무시하는.. 아니 관심이 없는 개발자들을 많이 본다.
Exception 정보야 말로 문제 해결의 근본적인 요소인데 말이다. 그리고 많이 헷갈리는 것 중에 하나가 바로 throw 와 throw(ex) 의 차이점
이다.
[ throw vs throw(ex) ] 그냥 보기에는 이 둘에는 차이점이 전혀 없어 보인다. 그러나 명확한 차이점이 존재한다.
try{
...
} catch (Exception ex) {
throw;
}
위의 코드는 catch로 Exception을 잡고 그냥 다시 throw 를 하는 것이고
try{
...
} catch (Exception ex) {
throw(ex);
}
위의 코드는 catch로 Exception을 잡고 그 Exception을 throw 하는 것이다.
위의 두 가지 모두 Exception을 catch 했고, 이를 다시 throw 하는 것에서는 같다. 그리고 같은 Exception Message를 제공한다는 점에서는 다른 점이 없다.
그럼 차이점은 무엇일까??? 굉장히 중요한 차이점이 있다. throw 는 현재 Context 상에서 발생한 Exception 정보를 온전하게 가지고 있다. 그러나 throw(ex) 는 처리 시점에 Exception을 Wrapping 하면서 기존의 Stacktrace 를 초기화하게 된다. 따라서 throw(ex)는 예외의 근본적인 정보를 소실할 수 있다는 점이다.
아래의 코드를 기준으로 점검을 해 보도록 하자.
using System;
namespace ThrowTest {
class Program {
static void Main(string[] args) {
try {
DevideByZero(10);
} catch (Exception exception) {
throw;
}
}
public static void DevideByZero(inti) {
int j = 0;
int k = i/j;
Console.WriteLine(k);
}
}
}
위의 코드는 Divide by zero Exception을 throw 한 것이다. 실행을 해 보면 다음과 같은 오류 출력을 볼 수 있다.
이제 위의 코드에서 throw 를 throw(exception) 으로 바꾸면 아래와 같이 오류 출력이 변경된다.
최종 오류 메시지와 throw(exception) 처리할 시점의 Stacktrace 정보만 남고, 더 이상의 정보는 제거되어 볼 수 없다. 따라서 오류에 대한 정확한 정보를 유지하기 위해서는 별도의 처리 후에 Custom Exception으로 변경하지 않는다면 당연히 throw 를 사용하는 것이 더 정확한 정보가 유지된다.
테스트는 닷넷에서만 진행을 했지만, 개념적으로는 Java에서도 동일하지 않을까 상상해 본다. 물론 백문이불여일타라고 항상 확인해 보는 습관을 가지도록 하자.
Written by Morris (MSFL).
- Total
- Today
- Yesterday
- SolrCloud
- Galera Cluster
- GIT
- operator
- Cluster
- 쿠버네티스
- leader
- macos
- Replica
- docker
- terrminating
- Kudo
- k8s
- custom resource
- CentOS
- operator framework
- ssh
- opencensus
- CentOS 8
- kudo-cli
- collection
- KUBECTL
- Kubernetes
- zookeeper
- provisioner
- galera
- Node
- Packages
- NFS
- dynamic nfs client provisioner
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |