休息例外：包裝器VS Error對象

比方說，我們有定義REST服務：休息例外：包裝器VS Error對象

@GET 
    @Produces("application/json") 
    public Response getAllCategories(@QueryParam(value="startIndex") int startIndex, @QueryParam(value="size") int size) 
    { 

     logger.info("[SampleCategoryController][getAllCategories]"); 

     List<YpCategory> categoryList = sampleCategoryService.getAllCategories(startIndex, size);  
     return Response.ok(categoryList).build();  
    }

和服務被定義爲：

public class SampleCategoriesServiceImpl { 

    public List<YpCategory> getAllCategories(int startIndex, int size) { 
     ... 
     //call some method that throws a runtime exception 
     ... 

    } 
}

和應用異常處理程序：

@Provider 
@Component 
public class ApplicationExceptionHandler implements ExceptionMapper<Throwable> { 

    @Override 
    public Response toResponse(Throwable ex) { 
      String internalError = "There was a problem processing your request."; 
      return Response.serverError().entity(new ExceptionResponse(500, internalError)).build(); 
     } 
    } 

}

異常響應對象：讓異常冒出來到ApplicationExceptionHandler並返回ExceptionResponse對象。這種方式似乎更清潔，因爲服務不必嘗試處理一個異常，它無法做任何事情，客戶端仍然會收到json響應。

響應包裝：類別對象將擴展某種類型的通用響應包裝對象與有關錯誤代碼的信息，然後我總是必須包裝可以在try/catch塊中引發運行時異常的方法，並設置錯誤代碼和catch塊中的消息信息。

其中一種方法是首選嗎？有沒有利用這些方法來處理錯誤？

來源

2015-11-26 mad_fox

我想你應該在這種情況下使用ExceptionMapper。讓異常在您的實現之外處理更爲清晰。你的實現也應該儘可能少地意識到HTTP。您的實現對框架其他部分的瞭解越少，它將變得越靈活。

舉個例子。可以說，將來會有對非HTTP協議的支持，而使用HTTP狀態代碼的錯誤消息傳遞將會不同。您可以在ExceptionMapper級別執行實施，而無需更改您的實施。否則，您必須重構應用程序以瞭解非HTTP協議。

只是要說清楚，我並不是說是現在有一個其他的實現。這只是一個理論。

來源

2015-11-26 15:05:40

休息例外：包裝器VS Error對象

回答

相關問題