ASP.NET Core，處理預期異常

Question

我正在 ASP.NET 核心中處理一個非常簡單的 CRUD 控制器，現在我面臨的問題是，我需要處理錯誤，例如使用不存在的實體（返回 404）或創建重復項（返回 400 ）。

所以現在我想知道在 ASP.NET Core 中獲取預期錯誤並為它們返回正確狀態代碼的最慣用的方法是什么。

一種方法是在負責實際 CRUD 的服務中拋出異常並在控制器內捕獲它們：

/// Inside service...
public void Create(Entity entityDetails) {
  if (entityAlreadyExists(entityDetails)) {
    throw new EntityDuplicateException();
  }
  // ...
}

/// Inside controller...
[HttpPost("{operatorClientId}")] 
public void CreateEntity(Entity entityDetails) {
  try {
   _entityService.CreateEntity(entityDetails);    

    return Ok();
  } catch (EntityDuplicateException e) {  // Some self defined exception type
    return BadRequest(/* Some details about the entity */);
  }
}

這對我來說似乎有點重復，因為很多代碼總是相同的，但乍一看它清楚地表明了對 API 的期望。 我認為當需要處理更多異常時，這也會變得有點混亂。

另一種方法是為 UseExceptionHandler 實現一個方法，其中所有異常類型的處理方式如下：

switch (exceptionHandlerPathFeature.Error)
{
    case EntityDuplicateException e:
        context.Response.StatusCode = 400;
        // More details to response here
        break;
    case EntityNotFoundException e:
        context.Response.StatusCode = 404;
        // More details to response here
        break;
    case {} e:
        context.Response.StatusCode = 500;
        // More details to response here
        break;
}

這將是處理預期（和意外）異常的一個地方。 但是您第一眼看不到控制器將返回什么。 並且在響應中獲取有意義的錯誤消息所需的所有信息會變得更加困難（在控制器中，每個信息都是直接可用的，我需要使用 ExceptionHandler 將所有信息包裝到異常中）。

Answer 1

異常，顧名思義，只應在特殊情況下使用， 而不應用於控制流。 未被發現或已經存在的實體也不例外； 這是您應該在數據訪問代碼中明確處理的常見情況。 另一方面，數據庫中的死鎖是。

不要讓您的數據訪問方法拋出異常，而是讓它們返回類似於(bool success, string errorMessage)的元組。 在控制器中，檢查success成員 - 如果它是false ，則將errorMessage返回給調用者。

至於你的全局異常處理程序，讓它保持通用。 它應該做的只是將所有異常記錄到一個中央位置，以便您可以定期檢查這些日志以確定您的應用程序是否真的定期遇到異常情況 - 在這種情況下您需要修復它。