Обработка исключений: что должен вернуть контроллер?

Question

У меня есть веб-API 2 действия контроллера, который возвращает список пользователей

public List<User> GetAll() 
{ 
    try 
    { 
     return _businessLogic.GetAll(); 
    } 
    catch (Exception ex) 
    { 
     ExceptionHelper.HandleException(ex, _logger, ControllerContext); 
    } 
} 

class ExceptionHelper { 
    public static void HandleException(Exception ex, ILogger _logger, HttpControllerContext controllerContext) { 
     _logger.LogError(ex); 
     // If possible handle the exception here 
     // Code for handling 

     // Throw it again 
     throw new HttpResponseException(
      controllerContext.Request.CreateErrorResponse(HttpStatusCode.InternalServerError, errorMessagError) 
     ); 
    } 
} 

C# компилятор жалуется, что не все кодовые пути в GetAll() возвращает значение. Дело в том, что я не хочу ничего возвращать, когда возникает исключение, потому что HandleException регистрирует ошибку и снова генерирует исключение. Как я могу прямо сказать, что я ничего не хочу возвращать.

Answer 1

попробовать этот путь

public List<User> GetAll() 
{ 
    List<User> result = new List<User>(); 
    try 
    { 
     result _businessLogic.GetAll(); 
    } 
    catch (Exception ex) 
    { 
     ExceptionHelper.HandleException(ex, _logger, ControllerContext); 
    } 
    return result; 
} 

Одна точка входа. Одна точка выхода. Лично я предпочитаю возвращать пустые списки, а что-то плохое происходит, а не возвращает null.

Answer 2

Как правило, вы должны обрабатывать исключения, если знаете, как обращаться с ним, и что вы хотите получить после исключения. Поскольку исключения относятся к поврежденному состоянию, вы либо можете восстановить состояние, либо не должны обрабатывать исключение.

Для примера выше, путь к удалению - это вообще исключить обработку исключений. То есть:

public List<User> GetAll() 
{ 
    return _businessLogic.GetAll(); 
} 

Что может пойти не так в GetAll методе:

• недоступного источнике данных (проблемы инфраструктуры);
• неверный запрос/модель EF/etc (проблемы с кодом).

В любом случае, все они полностью соответствуют HTTP 500 «Внутренняя ошибка сервера», поскольку на самом деле это ошибки сервера. Чем раньше вы получите обратную связь от пользователя, тем раньше вы их исправите.

Общей практикой является исключение журнала. Web API позволяет делать это на заказ, как, вводя свой собственный IExceptionLogger реализации:

public static void Register(HttpConfiguration config) 
    { 
     // ... 
     // ApiNLogLogger is a custom logger, that uses NLog 
     config.Services.Add(typeof(IExceptionLogger), new ApiNLogLogger()); 
    } 

Answer 3

Мы знаем, что HandleException выбросит исключение снова, но компилятор не знает, что. Поэтому, чтобы удовлетворить проверку компилятора, не изменяя слишком много кода, вы можете просто добавить внутри блока catch throw;. Хотя этот throw; будет недоступен, но проверка на компиляцию пройдет, и ваша функциональность будет работать должным образом. Пример ниже:

public List<User> GetAll() 
{ 
    try 
    { 
     return _businessLogic.GetAll(); 
    } 
    catch (Exception ex) 
    { 
     ExceptionHelper.HandleException(ex, _logger, ControllerContext); 
     throw;//Added throw to remove compilation error. 
    } 
} 

class ExceptionHelper { 
    public static void HandleException(Exception ex, ILogger _logger, HttpControllerContext controllerContext) { 
     _logger.LogError(ex); 
     // If possible handle the exception here 
     // Code for handling 

     // Throw it again 
     throw new HttpResponseException(
      controllerContext.Request.CreateErrorResponse(HttpStatusCode.InternalServerError, errorMessagError) 
     ); 
    } 
}