private void saveInboxMessages() { //
try {
synchronized (mStore) {
mStore.setContents(notiMessages);
mStore.commit();
}
} catch (Exception e) {
e.printStackTrace();
}
notiMessages = (Vector) mStore.getContents();
}
mStore에 notiMessages 라는 벡터를 인자값으로 setContents메소드에 넣어주면
mStore에 notiMessages의 값들을 참조하겠지..
근데 굳이 마지막에 notiMessages = (Vector) mStore.getContents(); 해서
다시 꺼내올 이유가 있을까 ..... -_-? 중간에 아무 연산과정도 없는데.. 넣을걸 왜 다시 빼주는걸까..
소스 전체적으로 보고 있는데 내가 생각하기에 어이없는 이런 로직들이 상당히 많아서 슬퍼진다...
내가 모르는 다른 무언가가 있는건가.....?
중간에 commit이라는게 보이는데?
예외를 감안한건가
commit은 메모리에 있는걸 파일로 저장하는 부분인데.. .getContents(); 하면 메모리에 있는 부분을 불러들이는거라... 실제로 아래 한줄 지워보고 실행시켜도 이상 없는거 같음
오늘 이런 종류의 소스 여러개 올려봐야겠다.. -_- 내가 파악 못하는 숨은 의도가 있을지 모르니...
커밋 실패해서 예외 발생하믄 , notiMessages 가 찐따라서 걍 버리고 , 바로 직전에 호출될때는 성공했다는 의미니까 , 성공했던 놈으로 다시 갱신시키는거 아님? , 걍 이거만 보면 그렇게 짐작
어떤 상태를 원래대로 돌려 놓을라는 개념 아님?
확인용으로도 볼 수 있는거 아님? 어쨋든 저런 코드를 작성한 걸 보니, 코드 작성자는 코드에 대한 섬세한 감수성이 있는 듯..
어셈에서 스택 사용할때 저런 비슷하게 하는 걸 본 것 같은데
음.. 나온 의견들을 토대로 테스트좀 해봐야겠음
어떤 언어 기반으로 만들었는지 모르겠지만.. synchronized 사용한 것을 보니.. 동시 동작하는 넘인 것 같넹. 그러면 다른 프로세서나 딴 넘이 같은 저장소 건더릴 수도 있을테니깐 저렇게 처리한 것 아닐까하는데. ㅇㅇ 혼자서 사용하는 프로그램임 ? 아니면 다중 접속 가능한 양상인것임 ?
만약 동시 동작이라면 저것을 어이없다고 생각해서 지워서 사고 터트리던 신입들 많이 봤음. ㅇㅇ
저거 지금 자바 맞지? 프갤에 자바개발자 있긴 있구남. 코드 물어보면 다들 C언어 쪽이더라고.ㅋ
v2.2횽이 하는말이 맞는듯.. synchronized 자바에서 여러놈들이 동시접근해서 생기는 문제를 보호할라고 하는거니
예외의 경우라면 catch 문 안에다가 넣었어도 되지 않나.. 굳이... 저렇게 밖에다가 뺄 이유가...
그리고 commit는 파일에다가 쓰는 메소드라서.. 예외가 발생하던 아니던.. setContents 해서 들어간 contents 값이 변할일은 없다고 보는데.. 파일저장에 예외가 발생하더라도 메모리에 남아있는 값은 그대로이기 때문에.. getContents가 파일에 저장되어 있는 값을 불러오는 메소드면 예외발생시 파일에 저장된 최근의 값을 불러드린 다는 추측이 맞지만... setContents 한 상태의 값을 그대로 가지고 오는 경우라..
commit위에다가 강제로 익셉션 발생시키고 log를 찍어봐야겠음.. 값의 변화가 있나..
코드가 좀 이상하네. 저기서 어떤 예외가 발생하는지 잘 모르겠는데 전부 퉁쳐서 Exception으로 받아버린 것도 좀 문제고(가독성 최악), 더군다나 exception 이 발생해도 그 밑에서 notiMessages 을 저장하는 로직은 여전히 수행되는데, 이러면 일관성이 깨져버리지. 위에서 예외 발생해서 실패했는데 밑에서는 여전히 뭔가를 담아두고 있네? 저러면 안되지.
나도 아놔콘다횽이랑 같은 생각으로 올린글인데.. 여러 의견들이 있어서.. 하나하나 의견 수렴해서 체크중
코드를 보니까 write-lock을 하려고 한거 같은데, 그러니까 읽을때는 동기화 안하고 써넣을때만 동기화를 하는 거... 어차피 저렇게 할거면 맨 마지막줄을 synchronized 안으로 넣는게 일관성 유지하는 측면에서는 더 나음... 왜 저런 이상한 코드가 나오냐면 100% 설계가 제대로 안된거임. 설계가 제대로 안되니까 이거 억지로 구현하려다보니 저런 코드가 나오는거임..
차라리 예외를 저 안에서 처리하는게 아니라 던져버리게 하든지..... 그러면 일관성이 깨지지는 않음.. 저거 짠 사람은 예외처리를 caller 가 할건지 callee가 할건지 제대로 구분을 못한 듯함... 코드의 맥락을 토대로 보건데 저기서 예외가 발생하면 던지는게 맞을 듯 함..
근데 마지막줄은 진짜 모르겠다
마지막줄은 저거 짠 사람이 나름대로 퍼포먼스 튜닝을 한다고 한 줄 넣은 것일 수도 있음...ㅋㅋ 그러니까, 지금 써넣고 나중에 또 읽어들일 바에야 어차피 써넣는 김에 마저 읽어서 일단 저장해놓자고 생각했을 수도 있음. notiMessages 이라는 변수가 클래스 내에서 어떤 식으로 참조되는지 확인해보면 알 수 있을 듯...