오류 및 예외 핸들링

이 주제에서는 C 프로그래밍 언어로 WebSphere Message Broker의 사용자 정의 확장을 개발할 때 고려해야 할 오류 및 예외 핸들링 관련 문제를 다룹니다. Java 프로그래밍 언어를 사용하여 사용자 정의 확장을 개발할 경우에는 표준 Java 오류 및 예외 핸들링 메소드를 사용할 수 있습니다. 예를 들면, WebSphere Message Broker가 내부적으로 예외를 전달할 경우, MbException 클래스의 Java 예외가 사용 가능하게 됩니다.

올바른 오류 및 예외 핸들링은 올바른 브로커 조작을 위해 중요합니다. 사용자는 사용자 정의 확장이 오류 및 예외를 핸들링해야 하는 시점 및 방법을 알고 있어야 합니다.

Message Broker는 C++ 예외를 생성하여 오류 조건을 핸들링합니다. 이러한 예외는 브로커의 관련 소프트웨어 계층에서 포착되어 그에 따라 처리됩니다. 그러나 C로 작성된 프로그램은 C++ 예외를 포착할 수 없으며, 전달된 모든 예외는 기본적으로 C 사용자 정의 확장 코드를 무시하고 Message Broker의 보다 높은 계층에서 포착됩니다.

유틸리티 기능은 주로 리턴 값을 사용하여 요청된 데이터(예: 브로커 오브젝트의 주소 또는 핸들)를 다시 전달합니다. 리턴 값은 때때로 실패가 발생했음을 표시합니다. 예를 들면, 브로커 오브젝트의 주소 또는 핸들을 검색할 수 없는 경우, 0(CCI_NULL_ADDR)이 리턴됩니다. 또한 오류 조건의 이유가 리턴 코드 출력 매개변수에 저장되며, 이 매개변수는 일반적으로 모든 유틸리티 기능의 기능 프로토타입의 일부입니다. 유틸리티 기능이 완료되고 returnCode가 널(null)이 아니면, returnCode에 CCI_SUCCESS가 포함됩니다. 그렇지 않은 경우에는 아래에 설명된 리턴 코드 중 하나가 포함됩니다. 유틸리티 기능이 완료되었는지 여부를 판별하기 위해 returnCode의 값을 항상 안전하게 테스트할 수 있습니다.

유틸리티 기능의 호출로 인해 브로커가 예외를 생성할 경우, 이 예외는 해당 유틸리티 기능에 대한 returnCode 매개변수에 값이 지정된 경우에만 사용자 정의 확장에 표시됩니다. returnCode에 널(null) 값이 지정된 상태에서 예외가 발생할 경우,

이것은 사용자 정의 확장이 자체 고유의 오류 복구를 수행할 수 없음을 의미합니다. 그러나 returnCode 매개변수가 지정된 상태에서 예외가 발생하면 CCI_EXCEPTION 리턴 코드가 리턴됩니다. 이 경우 cciGetLastExceptionData 또는 cciGetLastExceptionDataW(cciGetLastExceptionDataW가 유니코드 추적 텍스트가 포함될 수 있는 CCI_EXCEPTION_WIDE_ST를 리턴한다는 점과 다름)를 사용하여 발생한 예외의 유형에 대한 진단 정보를 확보할 수 있습니다. 데이터는 CCI_EXCEPTION_ST 또는 CCI_EXCEPTION_WIDE_ST 구조로 리턴됩니다.

해제할 자원이 없으면, 사용자 정의 확장에서 returnCode 인수를 설정하지 마십시오. 이 인수를 설정하지 않으면 예외가 사용자 정의 확장을 무시할 수 있습니다. 그런 다음 이러한 예외는 브로커에 의해 WebSphere Message Broker 스택의 보다 높은 계층에서 핸들링될 수 있습니다.

메시지 삽입은 CCI_EXCEPTION_ST 구조의 CCI_STRING_ST 구성원으로 리턴될 수 있습니다. CCI_STRING_ST를 통해 사용자 정의 확장은 필요한 삽입을 수신하는 버퍼를 제공할 수 있습니다. 브로커는 이 버퍼로 데이터를 복사하고 출력된 바이트 수와 실제 데이터 길이를 리턴합니다. 버퍼가 충분히 크지 않으면 데이터가 복사되지 않으며, 필요한 경우 "dataLength" 구성원을 사용하여 버퍼의 크기를 증가시킬 수 있습니다.

변경 시작returnCode에 널이 아닌 값을 설정하면 사용자 정의 확장이 필요한 경우 자체적으로 오류 복구를 수행할 수 있습니다. 이 유틸리티 함수는 사용자 정의 확장자로 되돌아가 returnCode를 통해 자신의 상태를 전달하도록 호출합니다. CCI_EXCEPTION이 returnCode에서 리턴되면, 추가 오류 복구가 수행되도록 모든 예외를 Message Broker로 다시 전달해야 합니다. 사용자 정의 확장자가 자체 오류 처리를 완료한 다음 cciRethrowLastException을 호출하여 이를 수행할 수 있습니다. cciRethrowLastException을 호출하면 C 인터페이스가 마지막 예외를 다시 전달하여 메시지 브로커에 있는 다른 게층에서 핸들링될 수 있습니다. C exit 호출과 마찬가지로 이 경우 cciRethrowLastException은 되돌아가지 않습니다.변경 끝

예외가 발생하여 사용자 정의 확장에 의해 포착될 경우 확장은 cciGetLastExceptionData, cciGetLastExceptionDataW 또는 cciRethrowLastException을 제외하고 어떠한 유틸리티 함수도 호출할 수 없습니다. 다른 유틸리티 기능을 호출하려 하면, 브로커의 무결성을 손상시킬 수도 있는 예상치 못한 작동이 초래됩니다.

사용자 정의 확장에서 심각한 오류가 발생하면 cciThrowException 또는 cciThrowExceptionW을 사용하여 Message Broker가 처리할 예외를 올바르게 생성할 수 있습니다. 그러한 예외의 생성으로 인해, 예외가 처리되지 않은 경우 제공되는 정보가 시스템 로그(syslog 또는 Eventviewer)에 기록됩니다. 추적이 활성 상태인 경우 정보는 또한 브로커에 기록됩니다.

예외 및 브로커 작동 유형

브로커는 사용자 정의 확장으로 전달할 수 있는 일련의 예외를 생성합니다. 이러한 예외는 오류 조건이 발견될 때 사용자 정의 확장에 의해 생성될 수도 있습니다. 예외 클래스는 다음과 같습니다.

치명적
브로커 프로세스가 안전하게 실행을 계속하지 못하게 하거나 브로커의 정책상 프로세스를 종료해야 하는 조건이 발생할 때 치명적 예외가 생성됩니다. 치명적 예외의 예는 중요한 시스템 자원을 확보하는 데 실패하거나 내부적으로 심각한 소프트웨어 오류가 포착된 경우입니다. 치명적 예외가 전달된 후에는 브로커 프로세스가 종료됩니다.
복구 가능한
원래 종료 지점이 아니더라도 현재 메시지 플로우의 처리를 종료해야 함을 의미하는 오류에 대해 복구 가능한 예외가 생성됩니다. 복구 가능한 예외의 예는 메시지 컨텐츠에 올바르지 않은 데이터가 있거나 출력 노드에 메시지를 기록할 수 없는 경우입니다. 복구 가능한 예외가 전달되면 해당 스레드에서 현재 메시지의 처리가 중지하나, 스레드는 해당 입력 노드에서 실행을 재개합니다.
구성
구성 예외는 구성 요청이 실패할 때 생성됩니다. 구성 요청의 형식에 오류가 있거나 데이터에 오류가 있으면 구성 요청이 실패할 수 있습니다. 구성 예외가 전달되면 요청이 거부되고 오류 응답 메시지가 리턴됩니다.
구문 분석기
구문 분석기 예외는 메시지 컨텐츠의 구문 분석이나 비트스트림의 작성을 방해하는 오류가 발생할 경우 메시지 구문 분석기에 의해 생성됩니다. 구문 분석기 예외는 브로커에 의해 복구 가능한 예외로 처리됩니다.
변환
다른 데이터 유형으로 변환할 때 올바르지 않은 데이터가 발견될 경우, 브로커 문자 변환 기능에 의해 변환 예외가 생성됩니다. 변환 예외는 브로커에 의해 복구 가능한 예외로 처리됩니다.
사용자
사용자 예외는 Throw 노드가 사용자 정의 예외를 전달할 때 생성됩니다.
데이터베이스
데이터베이스 예외는 데이터베이스 관리 시스템이 브로커 작동 중에 오류를 보고할 때 생성됩니다. 데이터베이스 예외는 브로커에 의해 복구 가능한 예외로 처리됩니다.
관련 개념
플로우 디버거
주의사항 | 등록상표 | 다운로드 | 라이브러리 | 지원 | 피드백
Copyright IBM Corporation 1999, 2006 마지막 갱신 날짜: 2006/08/21
as01430_