Бросок NotImplementedException на случае по умолчанию в операторе переключения
это не заставит кнопку панели задач высветиться в изменении цветов, но заголовок мигнет на и прочь пока они не переместят мышь. Это должно работать кросс-платформенное, и даже если у них просто есть он на различной вкладке.
newExcitingAlerts = (function () {
var oldTitle = document.title;
var msg = "New!";
var timeoutId;
var blink = function() { document.title = document.title == msg ? ' ' : msg; };
var clear = function() {
clearInterval(timeoutId);
document.title = oldTitle;
window.onmousemove = null;
timeoutId = null;
};
return function () {
if (!timeoutId) {
timeoutId = setInterval(blink, 1000);
window.onmousemove = clear;
}
};
}());
Обновление : можно хотеть посмотреть на использование уведомления .
HTML5
10 ответов
Если вы ищете значение, которое должно по определению соответствовать значению перечисления , и вы получили что-то еще, это определенно недопустимый аргумент.
Но теперь вы должны рассмотреть контекст.
Является ли метод частным и доступен только членам вашей библиотеки классов или приложения? Если это так, то это ошибка кодирования, которой НИКОГДА не должно быть. Утверждение и сбой.
Если, с другой стороны, это открытый или защищенный метод, к которому могут получить доступ клиенты, использующие вашу библиотеку, вам обязательно следует выдавать осмысленное сообщение (и желательно с хорошо известным типом исключения).
Важно помнить, что перечисления не проверяются по диапазону в Framework. Я могу указать, что для метода требуется параметр типа Environment.SpecialFolder; но он будет принимать любое 32-битное целое число.
Короче говоря, если ваш метод предназначен для общего пользования, да, в любом случае, бросайте. Если это не для общего пользования, Assert .
да, во что бы то ни стало, бросьте. Если это не для общего пользования, Assert . да, во что бы то ни стало, бросьте. Если это не для общего пользования, Assert .Это действительно зависит.
NotImplementedException для меня что-то вроде отметки todo. Значит, кто-нибудь придет потом доделывать код. Однако я не думаю, что это случай по умолчанию, которого не должно быть.
Когда вы проверяете состояние объекта, вы можете рассмотреть InvalidOperationException . Ваш метод предназначен только для работы с существующими случаями.
Когда вы выделяете входной параметр ArgumentException , всегда подходит.
В других случаях я предпочитаю NotSupportedException . Это немного указывает на то, что что-то не так с платформой или версией. И несовместимые версии кода являются истинным корнем проблемы, когда случай переключения по умолчанию, которого не должно происходить.
Может быть, не NotImplementedException, а ArgumentException. Это действительно будет зависеть от того, где вы его используете.
Звучит как разумный вариант.
Лично я бы создал исключение нового типа (возможно, InvalidEnumException или дал бы ему другое имя, которое будет понятным для службы поддержки) и выбросить его.
Я бы выбросил ApplicationException , потому что, если ваш код достигнет значения по умолчанию, а вы этого не ожидали, это означает, что что-то в вашем коде будет вести себя не так, как вы думали.
Это действительно зависит от вашего варианта использования. Будет полезно, если вы создадите исключение в первые дни интеграции. Пользователи вашей библиотеки могут сразу узнать об ошибках
Это действительно зависит от конкретного процесса, но да, это хороший процесс, чтобы ответить по умолчанию: на случай, если чего-то там не должно было быть.
Сначала вы должны подумать, что бы это значило, если бы вы получили значение за пределами известных случаев - что представляет собой включаемая переменная? Затем вы можете просто использовать тип исключения, соответствующий тому, что на самом деле происходит.
Что произойдет, если вы выбросите исключение? В каком контексте выполняется оператор switch? Должна ли случиться такая ситуация? Должно ли это когда-либо происходить во время выполнения в производственном коде? Охватывают ли ваши модульные тесты эту ситуацию? Если так, возможно, было бы лучше использовать assert.
Я бы сказал, по крайней мере, вы должны поместить туда Debug.Fail () .
Вы должны выбросить исключение в случае, если метод никак не может продолжаться. Но если вам нравится преобразовывать значения перечисления в строковые представления, тогда вы можете просто вернуть некоторую строку предупреждения. Продукт не выйдет из строя из-за очевидной ошибки, вероятно, найдется обходной путь, и все будут довольны.