Проверяет ли "http_status/100!= 2" лучше, чем "http_status!= 200",

Говоря о HTTPUrlConnection в своем блоге

ОТВЕТЫ

Ответ 1

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

Целочисленное деление означает, что все успешные коды состояния HTTP (т.е. те из 200-299) выражение false, а не только 200.

Не подражать Тиму Брей, но если бы я сам написал это и хотел четко выразить свое намерение, то для удобства чтения я, вероятно, захотел бы увидеть нечто вроде !statusCode.isSuccessful. Если вы не знали, что HTTP 2xx означает успешные коды статуса, не было бы очевидно, каково намерение целочисленного деления.

Конечно, целочисленное деление, вероятно, более совершенное, чем создание кучи гипотетических объектов StatusCode, а затем отправка метода isSuccessful на них. И производительность, вероятно, является ключевой целью для класса сетевой библиотеки.

Является ли http_status/100!= 2 лучше или быстрее, чем http_status!= 200?

Это не будет быстрее (две операции против одной), но будет ли это "лучше" сравнение яблок с апельсинами, поскольку эти две операции имеют другое поведение.

Ответ 2

http_status / 100 != 2 не совпадает с http_status != 200. Это по существу эквивалентно (http_status < 200 || http_status > 299) (помните, что все в этом диапазоне составляет "success" ).

Это говорит о том, что деление является ужасным и совершенно тупым. Я всегда использовал бы явное сравнение, потому что тогда намерение ясно.

Ответ 3

Я видел много кодов с жестко закодированной проверкой, и у меня часто возникали проблемы с этим подходом.

Когда я делаю рефакторинг для такого рода кода, подход, который я использую чаще всего, заключается в реализации проверки с помощью класса из javax-ws: javax.ws.rs.core.Response.Status.Family

что-то вроде этого:

if(Response.Status.Family.familyOf(responseCode).equals(Response.Status.Family.SUCCESSFUL)){
    //do your thing
}

Вы также можете проверить другие виды статуса:

  • ИНФОРМАЦИОННЫЙ - 1xx
  • УСПЕШНО - 2xx
  • НАПРАВЛЕНИЕ - 3xx
  • CLIENT_ERROR - 4xx
  • SERVER_ERROR - 5xx

JavaDoc: Response.Status.Family

Ответ 4

Предполагая, что http_status является целым числом (поэтому деление возвращает целое число), оно не лучше или быстрее, но отличается.

Он позволит любому статусу статуса 2nn запускать это условие. A 2nn код состояния...

... указывает, что действие, запрошенное клиентом, было получено, понято, принято и успешно обработано.

Источник.

Ответ 5

Один из сторон в пользу метода разделения Тима Брея для обнаружения сообщений уровня не-200 состоит в том, что проще unit test.

Этот метод ниже должен быть протестирован три раза; 2xx, 1xx и > 299.

(http_status < 200 || http_status > 299)

Этот метод требует только двух.

http_status / 100 != 2

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

Ответ 6

Обратите внимание, что в RFC 4918 введен код состояния 207 Multi Status. Это было предназначено для WebDAV, но некоторые разработчики могут найти его удобным, когда запрос относится к нескольким ресурсам (например: удаление группы заказов).

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

Я знаю, что это неправдоподобно, в сомнении лучше проверить API, который вы потребляете.

Ответ 7

Spring HttpStatus предоставляет методы, такие как is2xxSuccessful(), is4xxClientError() т.д., is4xxClientError() можно использовать для проверки, принадлежит ли HttpStatus к какому-либо конкретному семейству кодов состояния HTTP. Поэтому, если вы хотите обработать условие, если код состояния НЕ принадлежит 2xx, вы можете сделать следующее:

if (!HttpStatus.valueOf(http_status).is2xxSuccessful()) {
   // redirects, server errors, lions and tigers and bears! Oh my!
}