Когда утверждения должны остаться в производственном коде?
У вас есть один xml-файл для вашего ApplicationContext в этом файле есть тэг <mvc:annotation-driven />. Этот тег загружает разные ресурсы, связанные с сетью (просмотр разрешителей, сопоставления обработчиков и т. Д.), И поэтому необходимо, чтобы сервлет-api был доступен.
У вас уже должен быть сервлет api на пути к классу как предоставленная зависимость в maven.
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>3.0.1</version>
<scope>provided</scope>
</dependency>
Рядом с этим вы можете удалить тег <mvc:annotation-driven /> и поместить его в отдельном файле конфигурации. Это также тег, который должен (в общем говоря) быть загружен DispatcherServlet. (Я предполагаю, что applicationContext.xml по умолчанию загружен ContextLoaderListener).
11 ответов
Утверждения являются комментариями, которые не становятся устаревшими. Они документируют, какие теоретические состояния предназначаются, и какие состояния не должны происходить. Если код изменяется так состояния, позволенные изменение, разработчику скоро сообщают и должен обновить утверждение.
Я редко использую утверждения для чего-либо другая та проверка типа времени компиляции. Я использовал бы исключение вместо утверждения просто, потому что большинство языков создается для обработки их.
я предлагаю пример
file = create-some-file();
_throwExceptionIf( file.exists() == false, "FILE DOES NOT EXIST");
против
file = create-some-file();
ASSERT(file.exists());
, Как приложение обработало бы утверждение? Я предпочитаю старое try catch метод контакта с фатальными ошибками.
Большую часть времени, когда я использую утверждение в Java (утверждать ключевое слово), я автоматически добавляю некоторые производственные коды после. Согласно случаю, это может быть регистрирующееся сообщение, исключение... или ничто.
Согласно мне, все Ваши утверждения очень важны в выпуске dev, не в производстве повторно генерируют. Некоторые из них должны быть сохранены, другой должен быть отброшен.
Наше программное обеспечение сервера базы данных содержит и утверждения производства и отладки. Утверждения отладки просто, что - они удалены в производственном коде. Производственные утверждения только происходят если (a) некоторое условие существует, который должен никогда , существуют и (b) не возможно надежно восстановиться с этого условия. Производственное утверждение указывает, что с ошибкой в программном обеспечении встретились, или некоторое повреждение данных произошло.
, Так как это - система баз данных, и мы храним потенциально критические данные предприятия, мы делаем то, что мы можем для предотвращения поврежденных данных. Если условие существует, что может заставлять нас хранить неправильные данные, мы сразу утверждаем, откатываем все транзакции и останавливаем сервер.
Однако мы также стараемся избегать производственных утверждений в критических по отношению к производительности стандартных программах.
Утверждение является ошибкой, чистой и простой, и поэтому должно быть обработано как одна.
, Так как ошибка должна быть обработана в режиме выпуска тогда, Вам действительно не нужны утверждения.
основное преимущество я вижу утверждения, условный разрыв - их намного легче установить, чем развертка через окна VC для установки чего-то, что проводит 1 строку кода.
Если они обрабатываются так же, как любая другая ошибка, я не вижу проблемы с нею. Действительно примите во внимание, хотя это, неудавшиеся утверждения в C, как с другими языками, просто выйдут из программы, и это не обычно достаточно для производственных систем.
существуют некоторые исключения - PHP, например, позволяет Вам создавать пользовательский обработчик для отказов утверждения так, чтобы можно было отобразить пользовательские ошибки, сделать подробный вход, и т.д. вместо просто выхода.
В моем C++ я определяю, ТРЕБУЮТ (x), который похож, утверждают (x) за исключением того, что он выдает исключение, если утверждение перестало работать в сборке конечных версий.
, Так как неудавшееся утверждение указывает на ошибку, его нужно рассматривать серьезно даже в Сборке конечных версий. Когда производительность моего кода будет иметь значение, я буду часто использовать, ТРЕБУЮТ () для высокоуровневого кода и утверждают () для кода низшего уровня, который должен работать быстро. Я также использую, ТРЕБУЮТ вместо, утверждают, может ли состояние отказа быть вызвано данными, переданными в от кода, записанного третьим лицом, или повреждением файла (оптимально, я разработаю код конкретно, чтобы быть хорошего поведения в случае повреждения файла, но у нас не всегда есть время, чтобы сделать это.)
Они говорят, что Вы не должны показывать, что те утверждают сообщения конечным пользователям, потому что они не поймут их. Так? Конечные пользователи могут послать Вам электронное письмо со снимком экрана или некоторым текстом сообщения об ошибке, которое помогает Вам отладить. Если пользователь просто говорит, что "это отказало", у Вас есть меньше способности зафиксировать его. Было бы лучше отправить сообщения об отказе утверждения себе автоматически по Интернету, но который только работает, если у пользователя есть доступ в Интернет, и можно получить их разрешение.
Если профилирование не показывает, что утверждения вызывают проблемы производительности, я говорю, что они должны остаться в производственном выпуске также.
Однако я думаю, что это также требует, чтобы Вы обработали отказы утверждения несколько корректно. Например, они должны привести к общему типу диалогового окна с опцией (автоматически) сообщания о проблеме разработчикам, и не только выходе или разрушить программу. Кроме того, необходимо бояться использовать утверждения для условий, что Вы на самом деле позволяете, но возможно не любите или считаете нежелательными. Те условия должны быть обработаны другими частями кода.
Позвольте мне заключать в кавычки Завершенный Код Steve McConnell. Раздел по Утверждениям 8.2.
Обычно, Вы не хотите, чтобы пользователи видели сообщения утверждения в производственном коде; утверждения, прежде всего, для использования во время разработки и обслуживания. Утверждения обычно компилируются в код во время разработки и компилируются из кода для производства.
Однако позже в том же разделе, этот совет дан:
Для очень устойчивого кода, утверждайте и затем обработайте ошибку так или иначе.
я думаю, что, пока производительность не является проблемой, оставьте утверждение внутри, а скорее, чем дисплей сообщение, имейте ее, пишут в файл журнала. Я думаю, что совет находится также в Завершенном Коде, но я не нахожу его прямо сейчас.
Если Вы хотите сохранить их, заменяют их обработкой ошибок. Ничто худшее, чем программа, просто исчезающая. Я ничего не вижу неправильно с обработкой определенных ошибок как серьезные ошибки, но они должны быть направлены к разделу Вашей программы, которая оборудована для контакта с ними путем сбора данных, входа их и информирования пользователя, что приложение имело некоторое нежелательное условие и выходит.
Оставьте утверждения включенными в производственном коде, если вы не заметили, что программа работает значительно быстрее при их отключении.
если не стоит проводить измерения, чтобы доказать, что он более эффективен, то не стоит жертвовать ясностью ради игры »- Стив МакКоннелл 1993