none
Web API 2 : зачем нужен HttpResponseException? RRS feed

  • Общие обсуждения

  • Зачем вообще нужно это исключение? Его применение, я так понял, "ручное", т.е. мы сами его выбрасываем. Только следующие 2 метода возвращают одинаковый ответ:

            [Route("Get1")]
            [HttpGet]
            public HttpResponseMessage Get1()
            {
                var resp = new HttpResponseMessage(HttpStatusCode.NotFound)
                {
                    Content = new StringContent("ABC"),
                    ReasonPhrase = "phrase"
                };
                throw new HttpResponseException(resp);
            }
    
    
    
            [Route("Get3")]
            [HttpGet]
            public HttpResponseMessage Get3()
            {
                var resp = new HttpResponseMessage(HttpStatusCode.NotFound)
                {
                    Content = new StringContent("ABC"),
                    ReasonPhrase = "phrase"
                };
                return resp;
            }

    19 марта 2016 г. 22:09

Все ответы

  • А если представить себе систему несколько посложнее, где например больше одного вложенного метода? Наверное будет удобно кидать исключение где нибудь в другом месте не заботясь о том как передать нужный ответ "наверх"?

    This posting is provided "AS IS" with no warranties, and confers no rights.

    20 марта 2016 г. 1:00
    Модератор
  • А если представить себе систему несколько посложнее, где например больше одного вложенного метода? Наверное будет удобно кидать исключение где нибудь в другом месте не заботясь о том как передать нужный ответ "наверх"?

    This posting is provided "AS IS" with no warranties, and confers no rights.


    мне тяжело представить систему, где несколько уровней вложенности для View (в данном случае для API) слоя. Более нижний уровень уже будет уровень бизнес-логики и бросать там исключение, специфическое для API, как-то не комильфо. В бизнес-логике нужно кидать какое-то более общее исключение, описывающее проблему "абстрактно", а уже в API слое его перехватывать и обрабатывать (аналогично и для View в MVC)

    20 марта 2016 г. 15:02
  • Если у вас есть обработчики для централизованной обработки и логирования исключений, обычно оно так и бывает для сложной системы, то для первого случая они сработают, для второго нет. Вот вам и система не с одним уровнем вложенности :)

    Сделаем содержимое сообщества лучше, вместе!

    23 марта 2016 г. 11:16
    Модератор
  • Если у вас есть обработчики для централизованной обработки и логирования исключений, обычно оно так и бывает для сложной системы, то для первого случая они сработают, для второго нет. Вот вам и система не с одним уровнем вложенности :)

    Сделаем содержимое сообщества лучше, вместе!

    я стараюсь логировать  в самом верхнем слое (представлении):

    во-первых, там часто наиболее точно можно специфицировать ошибку (если это классический веб - то какие-то детали веб-запроса, если апи - опять же, детали заголовков и т.д.) и не нужно эти данные перебрасывать в более нижние только на случай логирования

    во-вторых, логируя в нижнем/среднем слое мне всё-равно нужно бросить вверх какой-то эксепшн, чтобы сообщить клиентской части, что что-то пошло не так.

    В среднем слое я обычно логирую то, что не нужно перебрасывать выше, т.е. или то, что можно перехватить и так оставить (что-то несущественное, ну не обновилось какое-то пятистепенное значение - ну и фиг с ним), или перехватить и обработать альтернативным путём. Остальное всё бросаю в обработку в самый верхний слой, где собственно и логгирую. В нижнем слое (БД) вообще ничего не логирую, наоборот, скорее даже кидаю экспешены искусственно

    23 марта 2016 г. 17:51