/// <summary>
/// Отлов ошибок.
/// </summary>public class ExceptionMiddleware : ExceptionFilterAttribute
{
public bool AllowMultiple => false;
public override void OnException(HttpActionExecutedContext context)
{
var actionContext = context.ActionContext;
if (actionContext != null)
{
// в UserAuthorize и UserRight атрибутах кидаются такие ошибки, и до пользователя доходила 500 ошибкаif (context.Exception is HttpResponseException ex &&
(ex.Response.StatusCode == HttpStatusCode.Unauthorized || ex.Response.StatusCode == HttpStatusCode.Forbidden))
{
throw context.Exception;
}
if (context.Exception is NotFoundException)
{
throw new HttpResponseException(actionContext.Request.CreateErrorResponse(HttpStatusCode.NotFound, context.Exception.Message));
}
if (context.Exception is AccessDeniedException)
{
throw new HttpResponseException(actionContext.Request.CreateErrorResponse(HttpStatusCode.Forbidden, context.Exception.Message));
}
и т.д.
стоит цель из сервиса пробросить в апишку (контроллер) чтоб он соотвственно вернул throw new HttpResponseException . можно на пальцах как это реализуется?
Здравствуйте, undo75, Вы писали:
U>вот класс есть
U>стоит цель из сервиса пробросить в апишку (контроллер) чтоб он соотвственно вернул throw new HttpResponseException . можно на пальцах как это реализуется?
А зачем так сложно?
Не позволяйте ошибкам проникал за границы компонентов.
Из методов сервиса возвращайте гарантированное значение.
В методе контроллера явно обработайте исключение.
Верните по запросу нужный код и сообщение.
Здравствуйте, Разраб, Вы писали:
Р>А зачем так сложно? Р>Не позволяйте ошибкам проникал за границы компонентов. Р>Из методов сервиса возвращайте гарантированное значение. Р>В методе контроллера явно обработайте исключение. Р>Верните по запросу нужный код и сообщение.
Когда речь идёт про "типичное" HTTP/REST API (в смысле, когда речь не идёт про "давайте по-быстрому сделаем REST API фасад для вот этого говна мамонта"), разделение на сервисы и контроллеры не имеет смысла, потому что сервису (а чаще — вообще слою доступа к данным) всегда нужен тот же самый контекст, который есть у контроллера (юзер, пермиссии, всякая там паджинация-фильтрация-сортировка), и наоборот — у сервиса обычно много причин завершиться более, чем одним образом, контроллеру надо знать — как именно. Тесты соответствующим образом писать сразу на HTTP/REST API.
Здравствуйте, undo75, Вы писали:
U>стоит цель из сервиса пробросить в апишку (контроллер) чтоб он соотвственно вернул throw new HttpResponseException . можно на пальцах как это реализуется?
Пишите код в контроллерах таким образом, чтобы оттуда не летели исключения (а если летели, то чтобы этот ваш глобальный хендлер транслировал их в 500). Если для этого нужно логику выносить прямо в контроллер — так и выносите:
HttpResponse getOrder(@PathParam("id") int id) {
Order o = ordersRepository.findById(id); // будет кидать если например база отвалилась - ок!
if (o == null) {
return MyFancyApiResponses.orderNotFound(id);
}
return MyFancyApiResponses.ok(o);
}