Это “Плохо” для использования выгоды попытки для управления потоком в.NET?
REST очень высокоуровневое понятие. На самом деле это даже не упоминает HTTP вообще!
, Если у Вас есть какие-либо сомнения относительно того, как реализовать REST в HTTP, можно всегда смотреть на Протокол Публикации Atom (AtomPub) спецификация. AtomPub является стандартом для записи УСПОКОИТЕЛЬНЫХ веб-сервисов с HTTP, который был разработан многими HTTP и светила REST, с некоторым входом от Roy Fielding, изобретателя REST и (co-) изобретатель HTTP сам.
На самом деле, Вы могли бы даже быть в состоянии использовать AtomPub непосредственно. В то время как это вышло из ведущего блог сообщества, это никоим образом не ограничивается блоггингом: это - универсальный протокол для того, чтобы УСПОКОИТЕЛЬНО взаимодействовать с произвольными (вложенными) наборами произвольных ресурсов через HTTP. Если можно представить приложение как вложенный набор ресурсов, то можно просто использовать AtomPub и не волноваться о том, использовать ли ПОМЕЩЕННЫЙ или POST, что Коды состояния HTTP возвратиться и все те детали.
Это - то, что AtomPub должен заявить о создании ресурса (разделите 9.2):
Для добавления участников к Набору клиенты отправляют запросы POST к URI Набора.
9 ответов
Вы не должны использовать исключения для потока управления просто потому, что это плохой дизайн. В этом нет смысла. Исключения составляют исключительные случаи, а не нормальный поток. Производительность, вероятно, не будет проблемой в этой ситуации, потому что для большинства современных приложений на современном оборудовании вы можете генерировать исключения в течение всего дня, и пользователь не заметит снижения производительности. Однако, если это высокопроизводительное приложение, обрабатывающее большой объем данных или выполняющее много какой-либо работы, то да, производительность будет проблемой.
На мой взгляд, это плохо, потому что это можно было бы сделать намного более понятным с помощью оператора if:
if (school != null) {
myLabel.Text = school.SchoolName;
}
else {
myPanel.Visible = false;
}
Это определенно позволит избежать ненужного использования обработки исключений и сделает смысл кода очень очевидным.
Исключения требуют дополнительных затрат времени выполнения, но здесь, вероятно, они незначительны. Будет разница в работе отладчика, но встроенные двоичные файлы должны работать примерно с той же скоростью.
Сообщите своему разработчику, что любой шимпанзе может создать код, который может прочитать машина. Хороший код написан для людей, а не для машин. Если вас беспокоит только нулевое исключение, то, вероятно, это ошибка в коде пользователя - никому не следует пытаться присвоить null таким образом. Вместо этого используйте оператор Assert () .
Вы абсолютно правы, что это плохо. Это плохо, потому что противоречит намерениям и , потому что вредит производительности.
Я понимаю, что есть место для разных стилей программирования, но лично я думаю, что, хотя это работает и я могу видеть, что пытается делать код, это также ухудшает читабельность и ясность кода, что значительно усложняет задачу. для программистов технического обслуживания. Здесь гораздо более уместен оператор if.
Создание исключений оказывает негативное влияние на производительность, см. http://msdn.microsoft.com/en-us/library/ms229009 (VS.80) .aspx
Мне никогда не нравится использовать исключения для управления потоком. Исключения обходятся дорого, и трудно определить, какой фактический поток программы с исключениями выбрасывается для достижения других мест в коде. Для меня это похоже на использование GoTo. Это не означает, что вам следует избегать исключений, скорее исключение должно быть именно таким, исключение из того, что обычно должно происходить в программе.
Я думаю, что хуже всего в коде то, что он даже ничего не делает за исключением. Нет записи в журнал или даже объяснения причин возникновения исключения.
Я согласен со всеми здесь - это ужасная идея.
В Java есть несколько случаев (я думаю, что они в основном исчезли, но могут все еще быть во внешних библиотеках ), где от вас требовалось перехватить исключение для определенных «неисключительных» случаев.
В общем, при написании библиотечного кода (ну, на самом деле любого класса) избегайте использования исключений для ВСЕГО, чего можно было бы избежать. Если возможно, что поле имени не задано, и это должно вызвать исключение в методе write (), обязательно добавьте метод isValid (), чтобы вам не нужно было перехватывать исключение вокруг записи, чтобы знать есть проблема.
(Приложение «Плохой код Java»): этот «хороший» стиль программирования практически исключает любую необходимость в проверенных исключениях в Java, а проверенные исключения в Java - это Suck.
Посмотрите это сообщение на тему «Почему бы не использовать исключения в качестве обычного потока управления?»
I think this is bad because it is coding against an exception for one and it will also inherit unnecessary overhead. Exceptions should only be caught if they are going to be handled in a specific way.
Exceptions should be caught specifically for Exceptional cases that you can not predict, in this case it is a simple check to see if school can be null, in fact it is expected that school might be null (since the label is set nothing). If school was null and it should not have been than it should throw its own ArgumentNullException.