반응형

자바(Java)에서 Exception을 잘 다루면 여러 상황에 대한 대응력과 유연성을 높일 수 있지만, 예외처리에 대한 일관된 기준이나 잘 정리된 설계가 없으면 어떻게 처리(handling)할 지 막막해지기도 한다. 그래도 코딩하는 과정에서, 내가 만든 특정한 클래스를 참조해서 쓰는 다른 (작성자가 나일 수도 있고, 다른 개발자일 수도 있는) 클래스에게 이 예외상황만큼은 반드시 명시적으로 인지하고 특별하게 처리하도록 하고 싶으면 메쏘드 제목에서 throws 구문으로 예외를 caller에게 전달해야 한다.


그런데 특정한 예외를 caller에게 전달하려고 throws로 예외를 명시했는데도 caller 쪽에서 그 예외를 catch하지 못하는 경우가 있는데, 알고 보니 throw 하는 예외가 상속 관계에 의해서 부모 예외 타입으로 다른 곳에서 먼저 catch되는 바람에 caller 쪽에서 처리하지 못했던 것이었다.



구체적인 상황은 다음과 같다:


UDP Datagram Socket을 이용한 메세지 송수신 역할을 담당하는 클래스가 있는데, 여기에 타임아웃(timeout) 기능을 추가해서 특정한 메세지 전송에 대해서 응답을 받기 위해서 UDP Socket을 열되, 일정 시간 동안만 기다리도록 만들 필요가 생겼다. 찾아보니 Socket 클래스의 setSoTimeout 메쏘드를 시간값 파라미터와 함께 호출하면 해당 시간이 지난 뒤에 자동으로 SocketTimeoutException을 발생시킨다는 사실을 확인했다. 


그래서 아래와 같이 sendMessageAndGetReply(String ip, int port, String msg, int timeout) 메쏘드를 정의하고 throws SocketTimeoutException을 추가로 적어 주었는데, 그럼에도 불구하고 caller 쪽에서는 SocketTimeoutException을 catch할 수가 없었다.



public static String sendMessageAndGetReply(String ip, int port, String msg, int timeout) throws SocketTimeoutException {

String reply = null;

byte[] sendData = new byte[1024];

byte[] receiveData = new byte[1024];

try {

DatagramSocket clientSocket = new DatagramSocket();

sendData = msg.getBytes();

DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, InetAddress.getByName(ip), port);

clientSocket.send(sendPacket);

DatagramPacket recvPacket = new DatagramPacket(receiveData, receiveData.length);

clientSocket.setSoTimeout(timeout); // 추가로 타임아웃을 명시적으로 설정한 부분

clientSocket.receive(recvPacket);

reply = new String(recvPacket.getData());

clientSocket.close();

} catch (UnknownHostException e) {

e.printStackTrace();

} catch (IOException e) {

e.printStackTrace();

}

return reply;

}



그런데 신기하게도 실행 화면에서는 SocketTimeoutException이 발생했다고 출력은 되는데, 정작 caller에서의 catch 구문은 실행되지 않았다.

코드의 다른 곳에서 해당 예외를 이미 처리했다는 의미인데, 알고 보니 sendMessageAndGetReply 메쏘드에서 catch (IOException e) 부분이 원인이었다. SocketTimeoutException은 java.io.InterruptedIOException을 extend한 자식 클래스이고, InterruptedIOException은 또한 IOException을 extend하고 있기 때문에, sendMessageAndGetReply가 해당 예외를 이미 처리해 버렸기 때문에, 제아무리 메쏘드 이름 옆에 throws로 명시해 두어도 throw가 되지 않았던 것이었다.


이것을 해결하기 위해서 결국 코드를 아래와 같이 고쳐야 했다. [2]


public static String sendMessageAndGetReply(String ip, int port, String msg, int timeout) throws SocketTimeoutException {

String reply = null;

byte[] sendData = new byte[1024];

byte[] receiveData = new byte[1024];

try {

DatagramSocket clientSocket = new DatagramSocket();

sendData = msg.getBytes();

DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, InetAddress.getByName(ip), port);

clientSocket.send(sendPacket);

DatagramPacket recvPacket = new DatagramPacket(receiveData, receiveData.length);

clientSocket.setSoTimeout(timeout); // 추가로 타임아웃을 명시적으로 설정한 부분

clientSocket.receive(recvPacket);

reply = new String(recvPacket.getData());

clientSocket.close();

} catch (UnknownHostException e) {

e.printStackTrace();

} catch (IOException e) {

if(e instanceof SocketTimeoutException){

// 자식 클래스 예외를 특별하게 처리

throw new SocketTimeoutException();

}

e.printStackTrace();

}

return reply;

}


이렇게 했더니 콜 스택이 짧아지긴 했지만, 그래도 caller 쪽으로 Socket TimeoutException만큼은 확실하게 넘어가는 것을 확인할 수 있었다.


결론적으로, 당연한 얘기지만 예외를 처리할 때, throw하려는 예외가 혹시 해당 위치에 이미 존재하는 다른 catch 구문에 의해서 같이 처리되지는 않는지 상속 관계를 바탕으로 꼼꼼하게 확인할 필요가 있다.




<참고자료>

[1] http://stackoverflow.com/questions/27797451/i-cant-catch-sockettimeoutexception

[2] http://stackoverflow.com/questions/20532855/why-cant-i-handle-exception-e-with-try-catch-clause



반응형
블로그 이미지

Bryan_

,
반응형
연구 코딩할 때마다 느끼는 점은, 왠지 나만 그런 것 같기도 하지만 ㅠㅠ 적합한 데이터 구조를 선택하는 것이 생각만큼 간단하지 않다는 것이다. 아니 좀더 정확하게 표현하면, 무엇이 적합한 데이터 구조인지는 뻔하지만, 그 구조가 어디서 어떻게 쓰일지를 미리 다 예측할 수 없어서 고민이다.

처음부터 몇 수 앞을 내다보고, 내가 구현한 실험환경이 어디까지 확장될 것인지를 염두에 둬서 요구사항 분석을 한다면 시행착오가 줄어들겠지만, 당장 실험결과를 빨리 그래프로 찍어내야 하는 마당에 장인정신(?)으로 이런 올라운드 플레이어 같은 제품을 천천히 제작할 수는 없는 노릇이다.

중간결론으로 얻은 것은... 결국 내 입장에서는 너무 지나치게 이런 선택의 문제가 조심스러워서 생각만 하느라 시간을 많이 허비한다는 것이다. 일단 방향이 아예 잘못되지 않았다면, 즉 통째로 뜯어고칠 위험을 최대한 줄였다면, 재빨리 구현해서 비효율적이더라도 돌아가는 코드를 먼저 얻는 것이 필요한 것 같다. 그 다음에 계속 고칠 것들은 버전업 한다는 생각으로 고쳐야 할 것 같다.

예를 들면 이렇다:

네트워크로 연결된 이웃노드의 실시간 상태정보를 저장하는 간단한 테이블 구조가 필요해서 처음에 ArrayList로 무작정 시작했다가, 중간쯤 구현해서 생각해 보니 무진장 자주 테이블 검색을 해야 되는데 그 때마다 O(N)의 검색시간을 소비하면 낭비일 것 같아서 O(1)로 줄어드는 Hashtable로 바꿨다.
그렇게 구현을 하다가, 이 테이블의 값을 실시간으로 로그 파일에 저장시키야 하는 요구사항이 추가되었다. 테이블은 매번 최신 값만 저장하고 있기 때문에 매 시간마다 테이블의 값들을 로그 파일에 한 줄씩 추가로 기록해야 하는데, 이 때 테이블에 항목이 추가된 시간 순서를 유지해야 한다.
처음에는 Hashtable에서 values() 메쏘드로 값들만 통째로 얻어 와서 나열하면 될 줄 알았는데, 생각해 보니 해쉬값에 따라 제멋대로 정렬돼서 나오기 때문에 시간 순서를 유지하지 않는 것에 잠시 멘붕...
결국 시간 순서대로 입력되는 새로운 키 값을 순서대로 저장하는 ArrayList를 하나 더 유지하고, 이걸 기준으로 Hashtable을 다시 탐색해서 파일에 기록하기로 했다.

문제는 위와 같은 테이블 구조가 한개만 있는 것이 아니라서 각 테이블 구조에 다 시간 순서의 ArrayList를 추가해야 되는 것...

처음부터 시간 순서대로 추가되는 키의 ArrayList와 Hashtable을 쌍으로 관리하도록 설계를 하고 이것을 상속받아서 다른 모든 테이블들을 구현했으면 좋았겠지만, 그러면 아직도 돌아가는 코드를 못 봤을지도 모르겠다.


마치 알파고가 바둑 게임에서 다음 수를 선택할 때, 계산할 시간이 충분한 경우와 제한적일 경우에 최적의 선택이 미묘하게 달라지는 것처럼 어쩌면 나도 경험이 부족하고 생각할 시간도 제한적인 상황에서 최선의 코딩 방향을 선택하는 것에 어쩔 수 없이 차이가 있음을 인정해야 할 것 같다.

이렇게 배워 가면서 점차 더 빠른 시간 안에 더 효율적으로 돌아가는 프로그램을 개발할 수 있게 되겠지. 꾸준히 연습하자.

반응형
블로그 이미지

Bryan_

,
반응형

자바에서 DatagramSocket (UDP 소켓)을 파라미터 없이 생성하거나, 포트 번호만 파라미터로 지정하면 특정 네트워크 인터페이스에 지정되는 것이 아니고, 인터페이스에 상관 없이 포트 번호만 맞으면 패킷을 주고 받는 식으로 작동한다.


실제로 인터넷에 검색해 보면 UDP 소켓을 특정한 네트워크 인터페이스에 지정하고자 하는 요구가 상당히 많은 것을 알 수 있다. 하지만 컴퓨터에 네트워크 인터페이스가 여러 개 있을 경우에 UDP 소켓에서 특정 네트워크 인터페이스를 지정하는 것이 Java Virtual Machine (JVM) 입장에서는 자연스럽지 않을 수 있다. "패킷이 컴퓨터 밖으로 나갈 때, 이를 내보낼 가장 적합한 네트워크 인터페이스를 선택한다"는 보편적인 논리에서 보면 이것은 원래 운영체제(OS)에 내장된 라우팅 프로토콜의 역할이기 때문에, User mode에 있는 JVM 위에서 돌아가는 자바 어플리케이션이 이 역할에 일부분 끼어드는 것처럼 보이는 것이다. 아무튼 자바 어플리케이션 입장에서 불가능하지는 않지만, 바람직한 구성은 아닐 수도 있다.


어쨌든 패킷을 받는 서버 입장에서 DatagramSocket을 생성할 때, 생성자(constructor) 파라미터에 특정 IP 주소와 포트 번호를 모두 파라미터로 넘김으로써 특정 네트워크 인터페이스에서만 패킷을 받도록 지정할 수는 있다.


byte[] receiveData = new byte[1024];

String ip = "192.168.3.4"; // 현재 컴퓨터의 특정 네트워크 인터페이스에 할당된 IP 주소

String port = 54321; // 원하는 포트 번호

DatagramSocket socket = new DatagramSocket(new InetSocketAddress(ip, port));

DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length);

socket.receive(receivePacket);


패킷을 보내는 클라이언트 입장에서는, 그냥 DatagramPacket을 보낼 때 destination IP 주소를 어떻게 지정하느냐에 따라서 특정 네트워크 인터페이스를 통한 전송 여부가 결정된다. 이것은 운영체제의 라우팅 테이블 설정을 따라간다.


byte[] sendData = new byte[1024];

// sendData에 대한 메세지 생성 작업 수행

String ip = "192.168.3.6";

int port = 54321;

DatagramSocket clientSocket = new DatagramSocket();

DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, InetAddress.getByName(ip), port);

clientSocket.send(sendPacket);


예를 들어, 리눅스의 route 설정이 유선랜 eth0과 무선랜 wlan0 모두 활성화되어 있고, default (0.0.0.0)에 대한 게이트웨이가 유선랜(eth0) 게이트웨이로 설정되어 있다고 가정하자. 이 때, 로컬 네트워크 밖에 있는 인터넷 상의 어떤 기기에 UDP 패킷을 보내고자 한다면, 자바 어플리케이션은 eth0을 통해서 패킷을 보낼 것이다. 이런 경우에 반드시 무선랜 wlan0으로 패킷이 나가도록 하고 싶으면 리눅스에서 route 명령으로 wlan0을 통해서 인터넷으로 나가는 경로를 설정해 주어야 한다.


문제는 서버의 입장에서 DatagramSocket에 특정 IP 주소를 지정해 버리면, 브로드캐스트(broadcast) 메세지를 받지 못하는 문제가 생긴다. 상대편에서 정확하게 IP 주소를 지정해서 보내는 경우에만 패킷을 받을 수 있고, 테스트해 본 결과, 가령 192.168.3.255 와 같은 destination IP로 전송되는 패킷은 받지 못했다.


이 경우에는 서버의 입장에서는 특정한 IP 주소를 지정하지 말고 모든 인터페이스와 모든 주소에 대해서 받을 수 있도록 해 두고, 일단 패킷을 받고 나서 전송자의 IP 주소 대역을 보고 판단하는 루틴을 코드에 추가하는 것이 좋을 것 같다. (이것이 best solution인지는 알 수 없으나, 현재로써는 이것이 working solution이다.)


byte[] receiveData = new byte[1024];

String port = 54321; // 원하는 포트 번호

DatagramSocket socket = new DatagramSocket(port);

DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length);

socket.receive(receivePacket);




반응형
블로그 이미지

Bryan_

,
반응형

OS: Windows 8.1 (64-bit)

Java: 1.8.0_60

Eclipse: Mars (64-bit)

프로젝트가 사용하는 JRE System Library: JavaSE-1.7



이클립스에서 프로젝트를 Export 명령으로 Runnable JAR 파일을 만들고 다른 환경(예를 들면 리눅스가 돌아가는 보드PC 같은 곳)에서 실행하려고 했는데 다음과 같은 에러가 발생했다:




Exception in thread "main" java.lang.UnsupportedClassVersionError: [실행하려는 클래스 이름] : Unsupported major.minor version 52.0

        at java.lang.ClassLoader.defineClass1(Native Method)

        at java.lang.ClassLoader.defineClass(ClassLoader.java:788)

        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:14                                                                    2)

        at java.net.URLClassLoader.defineClass(URLClassLoader.java:447)

        at java.net.URLClassLoader.access$100(URLClassLoader.java:71)

        at java.net.URLClassLoader$1.run(URLClassLoader.java:361)

        at java.net.URLClassLoader$1.run(URLClassLoader.java:355)

        at java.security.AccessController.doPrivileged(Native Method)

        at java.net.URLClassLoader.findClass(URLClassLoader.java:354)

        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)

        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)

        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)

        at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:482)



일단 .jar 파일을 돌리려는 대상 보드PC (Odroid)에 설치된 자바는 OpenJDK고 버전이 1.7.0_25다.
이클립스 프로젝트에서 JRE 라이브러리는 비록 1.7로 되어 있었지만, 이클립스가 실제로 사용하는 컴파일러는 1.8로 되어 있었기에 빌드한 버전이 맞지 않아서 생기는 문제였다.

해결하려면 Window > Preferences 에 가서,
Java > Compiler를 선택하고, 오른쪽에 보이는 화면에서 Compiler compliance level을 1.7로 설정한다.


그러면 현재 프로젝트들을 모두 새로 빌드할 것이다.
그 뒤에 다시 Runnable JAR 파일을 만들어서 실행하면 될 것이다.



반응형
블로그 이미지

Bryan_

,
반응형

Java 버전이 올라가면서 향상된 for 루프문(enhanced for loop) 문법이 나왔는데, 이것으로는 배열을 초기화할 수 없다는 사실을 발견했다.


예를 들어, 10개짜리 문자열 배열(String array)을 만들고 향상된 for 루프를 쓰게 되면 아래와 같이 코딩할 수는 있는데,

String[] strArray = new String[10];

for( String str : strArray ){

str = "test_string";

}


for( String str: strArray ){

System.out.println(str); // NullPointerException 발생

}


위와 같이 하면 배열의 각 문자열이 초기화되지 않고 여전히 null 상태로 존재하게 된다.

번거롭더라도 배열 초기화는 index number를 사용해서 아래와 같이 명시적으로 해 주는 것이 좋다.


for(int i=0; i<strArray.length; i++){

strArray[i] = "test_string";

}


이 문제는 String 뿐만 아니라 객체 배열(Object array), 기본 타입 배열(primitive type array; 예를 들어, int[], double[])에서도 마찬가지로 발생한다.

다만 기본 타입(primitive type) 배열의 경우에는 향상된 for 루프를 쓰더라도 NullPointerException은 발생하지 않지만, 값들이 0인 상태로 바뀌지 않은 채 존재할 것이다.



반응형
블로그 이미지

Bryan_

,