서비스 계층에서 예외를 throw해야합니까?

어떤 이유로 든 예외를 던지는 것을 싫어합니다. 성능 문제로 인해서이 문제를 다시 생각해 봐야할지 모르겠다.서비스 계층에서 예외를 throw해야합니까?

내 서비스 레이어 (Dao의 + 비즈니스 로직 등 사용)가 예외를 throw해야합니까?

public ModelAndView createProduct(@Valid ProductForm productForm, ..) { 
    ModelAndView mav = new ModelAndView(...); 

    if(bindingResult.hasErrors()) { 
    return mav; 
    } 

    // throw exception if user doesn't have permissions?? 
    productService.create(product, userPermissions); 

}

그래서 ProductService의 작성 방법에 내 옵션 : 사용자가 권한이없는

경우, 예외를
돌아 가기있을 것이다 응답 객체의 일종을 던져 성공/실패 플래그 및 오류 콜렉션과 함께 성공한 경우 신제품 ID.

유의해야 할 사항은 다음과 같습니다

은 또한 편안한 웹 서비스, 비 - 웹 응용 프로그램이 서비스 계층을 다시 사용할 수 있습니다.

모범 사례로 간주되는 사항은 무엇입니까?

출처

2012-05-01 loyalflow

다른 옵션이 있는지 물어보십시오. 때때로 예외가 필요합니다. 당신이 할 수있는 유일한 또 다른 일은 실패 또는 성공의 상태를 반환하고 적절하게 처리하는 것입니다.

출처

2012-05-01 21:11:34 JonH

서비스와 예외의 의미에 따라 다르지만 상황에 따라 HTTP 끝점에서 Java 예외가 발생합니다.

대답은 '아니오'입니다. 서비스는 일반적인 방법으로 오류를 노출해야합니다. See this article on MSDN (걱정하지 마세요). Restful 서비스의 경우 오류 코드와 함께 HTTP 상태로 전파되어야합니다. 이 서비스는 구현 세부 사항을 소비자에게 누설해서는 안됩니다. 그것은 자연적인 경계입니다.

소비자는 이러한 오류 상황을 처리하고 통신 할 대상을 결정해야합니다. 예외를 생성 할 수도 있습니다. 그러나 이러한 예외는 서비스가 오류 코드를 반환하도록 한 원래의 문제/해결책과는 별개입니다.

더 나아가 @yahir은 그가 말한 것과 똑같습니다. HTTP 서비스는 HTTP 오류를 노출하지만 다른 종류의 오류를 반환하는 다른 서비스를 사용할 수도 있지만 작업은 적절하게 처리하거나 매핑해야합니다.

출처

2012-05-01 21:17:55

나는 서비스 레이어가 클라이언트 코드에 노출 된 다른 메소드와 똑같이 동작해야한다고 말하고 싶다. 결국, 그게 정확히 무엇입니까.

RPC를 통해 클라이언트를 사용하는 클라이언트는이 동작을 정확하게 예상합니다.

REST와 같은 다른 실런트는 어쨌든 다른 랩핑 레이어 (예 : Controller 레이어)를 통해 서비스 레이어에 액세스해야합니다. 이 랩핑 레이어 임무 중 하나는 응답을 클라이언트 소비 가능으로 변환하는 것입니다.

출처

2012-05-01 21:25:50 yair

서비스 계층에서 예외를 throw해야합니까?

답변

관련 문제