.Net 클라이언트가 사용할 수있는 WSDL이있는 Java 기반 서비스를 작성 중이며 클라이언트에서 유효하지 않은 값을 받으면 내 클라이언트가 메시지 상자에 catch하고 표시 할 수있는 예외가 발생할 것이라고 생각했습니다. (클라이언트는 데스크톱 응용 프로그램입니다).서비스에서 클라이언트로 예외를 반환하는 것이 좋습니까?
이 방법을 사용하거나 더 나은 방법이 있는지 궁금합니다.
"아니오"라고 말합니다. 오류 메시지 등,하지만 예외를 직렬화하지 않을 것이다. 클라이언트가 누구인지 또는 그들이 작성한 언어가 무엇인지 전혀 알 수 없습니다.
서비스는 예외를 처리해야합니다. 잡아서 로그하고 합당한 오류 메시지와 상태 코드를 작성해야합니다. 이것은 제 생각에는 예외를위한 장소가 아닙니다.
"현명한 오류 메시지"라고 할 때 스택 추적과 비슷한 의미는 아닙니다. 이들은 비즈니스 클라이언트가 될 가능성이 있으며, 그러한 것들을 읽지 않아야합니다. 비즈니스 의미있는 메시지는 스택 추적이 아닌 티켓입니다.
우선 처리해야 할 데이터에 대한 유효성 검사를 수행하여 예외가 발생하는 것을 막습니다. IE는
string func(string cat)
if(cat == null || cat.length == 0){
//set errorLabelText to "bad data"
return;
}
//else code
만 말했다되고 그건 예외적 인 경우에 예외를 throw합니다.
.NET에서는 일반적으로 WCF의 FaultExceptions (랩 된 SOAP 오류)을 처리합니다. 적절한 SOAP 오류를 throw하면 WCF는 클라이언트가 응답을 소비 할 때까지 FaultException으로 랩핑하여 FaultException 문을 try catch 할 수 있다고 가정합니다. 이것은 여전히 .. 다른 비 .NET 클라이언트가 파괴 기준없이 서비스를 소비 할 수 있도록 할 그냥 생각 어쨌든
...개념적으로이 괜찮지 만, 나는 당신이 할 수 그대로 던져 생각하지 않는다 HTTP를 통한 Java 예외 다시 .NET 클라이언트로.
HTTP 500을 사용하여 서버 오류를 알릴 수 있습니다. .NET 개발자가 서비스를 더 잘 사용하는 방법을 파악하는 데 도움이되는 의미있는 메시지를 응답에 첨부 할 수 있어야합니다. 직렬화 된 Java 스택 추적을 포함 할 수도 있고 포함하지 않을 수도 있습니다.
SOAP 오류는 모든 클라이언트에서 지원되어야하므로 SOAP Fault를 사용해야합니다. 추가 설명 필드도 설정해야합니다.
@duffymo : 대부분의 요점에 동의 하겠지만 서비스에서는 API를 통해 위생적인 예외를 반환하는 것이 좋습니다. 실제 예외를 잡아서 기록하고, 누락 된 메시지와 실제 스택 추적없이 새로운 예외를 반환합니다. –
^더 이상 동의 할 수 없습니다. –
아, 그래서 위생 처리 된 예외 나 msg를 응답 객체로 감싸서 반환하는 것이 낫겠습니까? 말이된다. 감사! –