정말 정상적인 상황이라면 예외가 발생하지 않는데, 발생하면 예외 처리가 귀찮아짐..
언어별로, 운영체제별로 IO처리에 대한 예외 방법은 제공해주지만
무조건 이렇게 쓰세요! 라는 강제적인 코드 구조는 없음..
결국 예외 처리하는 큰틀은 동일하나 짜는 사람마다 방법이 조금씩 다른데,
이걸 테스트 또 테스트 해보려면 실제 필드가 아닌 이상 개발 머신에서 IO 예외를 만들어 본다는게 힘듦 ㅋㅋㅋ
파일 IO까지는 그냥 귀찮은거지 예외가 뻔하니깐..
스토리지 중간에 뽑히거나 박살나는 경우가 아니면 예외를 직접 만들어 보면 되는거지..
근데 소켓은 예외가 너무 다양할 뿐더러, 내가 직접 만들어 볼 수 있는 예외는 몇 안됨..
랜선 뽑히거나, 중간에 RST를 받았거나, 읽기 또는 쓰기 가능 상태가 아니라고 하는거나 이정도?
읽기 또는 쓰기 가능상태도 메모리가 꽉차서 뜨는 경우는 별로 없어서 진짜로된 예외를 보기 힘듦 ㅋㅋ
사실 소켓에서 위 예외를 제외하곤 겪어 본적이 없어서 저 예외가 아니면 어찌 처리해야할지도 모르겠음 ㅋㅋ
그냥 죽는게 최선이기도 한것 같고..
후...
9개의 댓글
무분별한 사용은 차단될 수 있습니다.
고양이를죽인원앙
걍 socket관련 예외는 다잡고 로그남겨서 그때그때 처리하는수밖에?
잉텔
예외를 다 잡고 로그를 남겨도 예외가 너무 한정적임..
본문에 적었듯이 본문에서 언급한 3가지 예외만 잡아도 99%의 예외는 잡는데, 1%예외가 걱정되는겨..
고양이를죽인원앙
그걸 어떻게 예측하고 잡어 ㅋㅋ 우주선도 아니고 걍 문의하라 하는수밖에
잉텔
그래... 그냥 죽으면 다시 프로세스 살리는 방향으로 가야겠다.. ㅋㅋ
번한강행
커넥션 도중에 클라이언트가 비정상적으로 종료해서 소켓만 물고있는 경우도 있고
Lost가 너무 심해서 어느 순간 이후부터는 패킷이 오지 않는 경우도 있고
백신때문에 연결이 중간에 차단되는 경우도 있고
그리고 예외는 아니긴 한데 악의적 공격자가 커넥션 고갈시키는 상황도 생각을 해야하고...
그래서 소켓은 생각해볼게 너무 많음 ㄹㅇ
잉텔
비정상 종료야 예외에 잡혀서 close해버리고 fd리스트에서 없애면 되겠는데..
로스가 심해서 RST도 씹히거나, 백신이 지랄하면 생각해볼 예외가 장난 아님 ㅋㅋㅋ
잉텔
SYN flood는 내 문제 아니니깐 냅두자.. ㅋㅋ
buruburu
죽으면 다시 켜면 되지
잉텔
차피 graceful 하게 예외처리 못할거면, 그냥 graceful 하게 죽고
모니터가 프로세스를 감시하다가 5번 이상 죽으면 시스템 재부팅 하는걸로 바꿈 ㅋㅋ