2008-09-26 4 views
2

서버와의 TCP 소켓 통신을 캡슐화하는 클래스가 있습니다. 서버로 보내지는 각 명령 메시지에 대해 서버는 항상 응답 코드 (OK, Fail)가 포함 된 응답 메시지를 되돌려 보냅니다. 내 클래스를 사용하면 각 명령을 동기화 또는 비동기로 실행할 수 있습니다.예외 vs 소켓 클라이언트 클래스의 결과 코드

기본적으로 두 가지 유형의 예외가 발생할 수 있습니다. 연결이 끊어 지거나 "복구 버퍼가 가득 찼습니다"와 같은 예기치 않은 예외로 인해 발생한 "오류"입니다. 오류가 발생하면 연결이 다시 설정 될 때까지 명령을 계속하거나 다시 시도 할 수 없습니다. 실패 응답 또는 예외 상황이 발생하면 다시 명령을 시도 할 수 있습니다 ...

이제 sync 명령 메서드는 다음 값을 가질 수있는 열거 형을 반환합니다. OK, Fail, Fault. 예외가 발생하면 단순히 호출하는 스레드로 보내집니다 (sync 명령에서). 비동기 명령의 경우 Result 속성 enum 값에 OK, Fail, Fault 또는 Exception이라는 추가 값이 포함될 수 있으며 콜백은 명령 객체의 Exception 속성을 통해 실제 예외 객체에 액세스 할 수 있습니다.

이 전략에 대해 어떻게 생각하십니까? 동기화 명령에 대한 예외를 전혀 발생시키지 않고 내부적으로 예외를 기록하고 대신 네 번째 열거 형 값을 반환하는 유혹을받습니다. 그 이유는 모든 경우에 예외로 처리하기 때문입니다 ... 또는 사용하지 않아야합니다. 결과 코드를 전혀 작성하지 않고 모든 경우에 예외를 발생시킵니다.

감사합니다.

+0

답장을 보내 주셔서 감사합니다. 이 스레드에서 얻은 값은 기본적으로 "예외적 인 조건에 대한 예외 사용"을 상기시키는 것입니다. 그래서 나는 그 첫 번째 사람에게 대답했다. 여러 답을 줄 수 있다면 그렇게 하겠어! –

답변

1

나는 전략이 기본적으로 건전하다고 생각합니다.

예외의 목적은 예외적 인 조건을 처리하는 것입니다. 문제의 근원에 가까울수록 좋습니다.

귀하의 경우 전략은 "지금은 작동하지 않았습니다. 다시 시도해보십시오."라고 표시됩니다. 나는 정말로 예외를 제기 할 이유가 보이지 않습니다.

닫힌 소켓을 다루는 것이 코드에서 완전히 다른 흐름을 필요로한다면 뭔가 예외가있을 수 있습니다. 귀하의 설명에서, 그것은 사실이 아닙니다.

예외에 대한 나의 철학은 그들이 정말로 다룰 수없는 예외적 인 조건을위한 것이어야한다는 것입니다. 닫힌 소켓? 음 ... 몇 번이나 인터넷이 내 집에 내려갑니다 ...

0

결과 코드와 예외가 모두 제대로 작동 할 수 있습니다. 그것은 개인적인 취향 (그리고 당신 팀의 다른 사람들의 취향)의 문제입니다. 예외는 특히 복잡한 설정에서 몇 가지 장점을 가지고 있지만 설정에서 반환 코드가 제대로 작동 할만큼 간단한 것처럼 들립니다.

일부 사람들은 입안에서 거품을 일으키고 예외를 주장 할 것이지만 반환 코드의 단순성과 같은 프로젝트 사람들에게는 전반적인 더 나은 선택이 될 것입니다.

0

이것은 다소 흥미로운 질문입니다. 따라서 '100 % 정확함'의 대답은 없으며 대부분 함수를 사용하는 코드가 어떻게 구조화되어야한다고 생각 하느냐에 달려 있습니다.

내가 보는 방식은 함수를 호출하는 코드에 '비참한'상황에서 정상적으로 벗어날 수있는 방법을 제공하려는 경우에만 예외를 사용하는 것입니다. 그래서, 내 코드에서 예외가 발생하면 실제로, 정말 끔찍한 일이 발생하고 호출자는 알아야합니다.

정상적인 상황에서 기대 한 상황이라면 오류 값을 반환해야합니다. 그런 식으로 코드는 '열심히 노력'해야한다는 것을 알고 있지만 일어난 일에 의해 손상되지는 않습니다.

예를 들어, 타임 아웃을 예상 한 것으로 처리하여 오류 코드를 반환하고 호출 코드가 몇 가지 추가 작업을 수행해야하는 더 심각한 문제 (전체 송신 버퍼와 같은)를 반환 할 수 있습니다 예외로 '정상'으로 돌아갑니다.

그러나 아름다움은 보는 사람의 눈을 사로 잡고, 어떤 사람들은 예외 만 사용하고 나머지는 (대부분 C 프로그래머) 리턴 코드 만 사용하도록 말합니다. 다만 항상 예외는 예외다는 것을 기억하십시오. :)

1

귀하의 방법이 성공적으로 임무를 완료하지 못할 때 언제든지 예외를 던집니다. 따라서 호출자 인 yourObject.UploadFile()을 호출하면 호출이 반환 될 때 파일이 성공적으로 업로드되었다고 가정합니다. 어떤 이유로 든 실패하면 개체가 예외를 throw합니다. 재 시도 할 수있는 명령과 재 시도하지 말아야하는 명령을 구별하려면 해당 정보를 예외에 넣고 그에 따라 대응할 방법을 결정할 수 있습니다.

yourObject.BeginAsyncUploadFile()을 호출 할 때 파일 업로드 성공 여부를 알아 내기 위해 IAsyncResult 또는 이와 동등한 개체를 기다릴 필요가 있다는 것을 제외하고는 동일한 동작이 예상됩니다. 예외/그렇지 않은 경우 Error 속성.