ASP.NET MVC 4, бросить HttpException и вернуть HttpStatusCodeResult?

Я разрабатываю службу RESTful, и я хочу вернуть 400 для всех неподдерживаемых URL-адресов.

Мой вопрос , когда я должен выбрать метод 1 по методу 2 и наоборот.

//method 1
public ActionResult Index()
{
    //The url is unsupported
    throw new HttpException(400, "Bad Request");
}

Кажется, что это лучше?

//method 2
public ActionResult Index()
{
    //The url is unsupported
    return new HttpStatusCodeResult(HttpStatusCode.BadRequest, "Bad Request");
}

Ответ 1

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

Ответ 2

На мой взгляд, сначала нужно учитывать, если запрос на неподдерживаемые URL-адреса. Тогда вы думаете, что это исключительная ситуация, или вы ожидаете, что это произойдет? Если вы считаете это исключительной ситуацией, создайте и выбросите исключение (вариант 1). Если вы ожидаете, что получите много запросов на неподдерживаемый URL-адрес, рассмотрите его как функцию вашего приложения и используйте метод 2.

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

Ответ 3

Будучи в команде DevOps, мы все находимся в сознании, где бросаем больше аппаратных средств на что-то, чтобы немного улучшить результат всегда является хорошей причиной. Поэтому я намеренно игнорирую микрозатраты на исключение .NET.

Если вы используете платформу телеметрии, например ApplicationInsights, то просто возврат кода состояния дает вам не что иное, как "неудачный запрос". Он не дает вам никакой полезной информации, которая позволяет либо скомпилировать, либо получить любую информацию о "почему" неудавшегося запроса.

Платформы телеметрии ожидают и хотят, чтобы вы выбрасывали, потому что телеметрия ошибок обычно связана с исключениями .NET, поэтому, если вы не бросаете, вы создаете проблему для операций.

Я действительно приземлился здесь, потому что я в процессе написания анализатора Roslyn и CodeFix для проекта, где люди любят писать try{} catch { return BadRequest("put_the_reason_here"); }, и ни DevOps, ни команды Dev не видят ничего полезного в телеметрии телеметрии в ApplicationInsights.

Ответ 4

Хотя этот вопрос немного устарел, я подумал, что дам свой вклад, так как я наткнулся на это.

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

Я иногда использую (слегка расширенный) Exception, не бросая их в следующий контекст выполнения, чтобы извлечь полезную информацию об отладке, о которой упомянул Дэвид Родригес. Никогда не бывает оправдания тому, чтобы передавать исключенные исключения из контекстов выполнения, которые вы на самом деле не исключительны, и это действительно применимо только к вещам, которые на самом деле находятся за пределами способности вашего кода обрабатывать (StackOverflowException, другие фатальные системные исключения и т.д.),

В сетевом приложении, таком как любая работа MVC, которую вы выполняете, штраф за выполнение исключений от бросания не имеет смысла. Семантика и влияние на ремонтопригодность не являются.

Сетевые ошибки - это значения, и вы должны обращаться с ними так.