레거시 클라이언트가 COM을 사용하여 중간 계층에 계속 액세스 할 수있게하려면 dll을 만들어야합니다. 새로운 중간 계층은 WCF/.net 4.5를 사용하므로 COM을 통해 .net 4.5 dll을 노출합니다.COM의 .net 오류 처리
제 질문은 오류를 반환하는 방법/오류가 발생했을 때 반환 할 내용입니다. 이것에 대한 정보가 거의 없습니다. 현재 찾을 수있는 기존 클라이언트에는 오류 처리가 없으므로이를 벤치 마크로 사용할 수 없습니다.
표준 try/catch 방식을 사용하고 .net 오류를 발생시킨 다음 클라이언트가이를 정렬하도록 할 수 있습니까? 아니면 이런 종류의 시나리오에서 오류 처리를 활성화하기 위해 더 많은 작업이 필요합니까?
불행히도 이것은 세부적인 사항은 아닙니다. COM 클라이언트 코드가 반환 값 HRESULT를보고 특정 값에 반응하는 것은 드문 일이 아닙니다. 버그 해결 방법 일 수도 있고 사용자 정의 오류보고 일 수도 있으며 "실패 할 것으로 예상됩니다. 다음에이 작업을 수행하십시오"코드 흐름 일 수 있습니다. 그런 종류의 코드는 얼마나 복잡합니까? COM 구성 요소가 얼마나 오랫동안 지속되었고 얼마나 귀찮았는지와 관련이 있습니다.
그러나 예, 매우 역 엔지니어링하기가 어렵습니다. 클라이언트 코드 프로그래머를 인터뷰하고 그가하는 일을 묻는 기회를 찾으십시오. 원본 코드를 검토하십시오. 이전에 특정 HRESULT를 반환 한 곳이면 .NET 교체에서 다시 해당 작업을 수행해야합니다. Marshal.ThrowExceptionForHR()을 사용하십시오.
.NET 자체는 좋은 COM 오류보고에 대한 훌륭한 지원을 제공합니다. [ComVisible] 클래스 메쏘드에 던진 예외는 자동으로 잡아서 호출자에게 반환 된 HRESULT에 매핑됩니다. CLR은 IErrorInfo를 구현하여 클라이언트가 HRESULT 이상의 텍스트 설명을 포함하는 부유 한 오류 정보를 얻을 수 있도록합니다. 그래서 Exception.Message는 클라이언트가 인터페이스를 사용한다고 가정 할 때 잃어 버릴 필요가 없습니다.
모든 표준 .NET 예외 파생 개체는 COM에서 허용하는 한 논리적 매핑을 사용하여 특정 HRESULT에 매핑됩니다. OutOfMemoryException은 E_OUTOFMEMORY에 매핑되고 ArgumentException은 ERROR_INVALID_PARAMETER에 매핑되고 IOException은 원래 winapi 오류 코드 등으로 매핑됩니다. 클라이언트 코드가 HRESULT 만 표시하거나 기록하는 경우에도 원본 .NET 예외로 다시 매핑하는 방법은 여전히 있습니다.
물론 Holy Stack Trace가 없으면이를 로깅하는 것이 좋습니다. 시도/잡기/던지기 코드를 작성하는 것은 매우 고통 스럽지만 칩이 떨어지면 절대적으로 가치가 있습니다. 그들은 내려갈 것이다.