Отладка. Утверждайте по сравнению с определенными вызванными исключительными ситуациями
Я только что начал просматривать 'MS Отладки.Net 2.0 Applications John Robbins и стал смущенным его евангелизмом для Отладки. Утверждайте (...).
Он указывает, что хорошо реализованный Утверждает, хранят состояние, несколько, состояния ошибки, например:
Debug.Assert(i > 3, "i > 3", "This means I got a bad parameter");
Теперь, лично, кажется сумасшедшим мне, что он так любит вновь заявлять о своем тесте без фактического разумного комментария 'бизнес-логики', возможно, "меня <= 3 никогда не должен происходить из-за flobittyjam widgitification процесс".
Так, я думаю, что добираюсь, Утверждает как своего рода низкий уровень, "Давайте защитим мои предположения" вид вещи... предполагающей, что каждый чувствует, что это - тест единственные потребности сделать в отладке - т.е. Вы защищаете себя от коллеги и будущих программистов, и надеетесь, что они на самом деле тестируют вещи.
Но то, что я не получаю, он тогда продолжает, что необходимо использовать утверждения в дополнение к нормальной обработке ошибок; теперь то, что я предусматриваю, является чем-то вроде этого:
Debug.Assert(i > 3, "i must be greater than 3 because of the flibbity widgit status");
if (i <= 3)
{
throw new ArgumentOutOfRangeException("i", "i must be > 3 because... i=" + i.ToString());
}
Что я получил Отладкой. Утверждать повторение теста состояния ошибки? Я думаю, что получил бы его, если бы мы говорили о перепроверке только для отладки очень важного вычисления...
double interestAmount = loan.GetInterest();
Debug.Assert(debugInterestDoubleCheck(loan) == interestAmount, "Mismatch on interest calc");
... но я не получаю его для тестов параметра, которые, конечно, стоит проверить (и в ОТЛАДКУ и в Сборки конечных версий)... или нет. Что я пропускаю?
2 ответа
Вот на 2 цента.
Я думаю, что лучший способ - использовать как утверждения, так и исключения. Основные различия между двумя методами, imho, если эти утверждения Assert могут быть легко удалены из текста приложения (определяет, условные атрибуты ...), в то время как выброшенное исключение зависит (типично) от условного кода, который сложнее удалить ( многострочный раздел с условными выражениями препроцессора).
Каждое исключение приложения должно обрабатываться правильно, а утверждения должны выполняться только во время разработки и тестирования алгоритма.
Если вы передадите ссылку на нулевой объект в качестве обычного параметра и используете это значение, вы получите исключение с нулевым указателем. Действительно: зачем писать утверждение? В данном случае это пустая трата времени. Но как насчет частных членов класса, используемых в классовых подпрограммах? Когда эти значения где-то установлены, лучше проверить с помощью утверждения, установлено ли нулевое значение. Это только потому, что, когда вы используете член, вы получаете исключение нулевого указателя, но вы не знаете, как было установлено значение. Это приводит к перезапуску программы, которая прерывается при использовании всех точек входа для установки закрытого члена.
Исключения более полезны, но ими может быть (imho) очень сложно управлять, и есть возможность использовать слишком много исключений. И они требуют дополнительной проверки, возможно, нежелательной для оптимизации кода. Лично я использую исключения только тогда, когда код требует глубокого управления перехватом (операторы catch находятся очень низко в стеке вызовов) или когда параметры функции жестко не запрограммированы в коде.
Используйте RotateAnimation , установив опорную точку в центре изображения.
RotateAnimation anim = new RotateAnimation(0f, 350f, 15f, 15f);
anim.setInterpolator(new LinearInterpolator());
anim.setRepeatCount(Animation.INFINITE);
anim.setDuration(700);
// Start animating the image
final ImageView splash = (ImageView) findViewById(R.id.splash);
splash.startAnimation(anim);
// Later.. stop the animation
splash.setAnimation(null);
Вы можете просмотреть следующие статьи, в которых описаны несколько примеров:
- Почему CouchDB отсасывает
- Переполнение стека - Когда использовать CouchDB vs RDBMS
- Когда использовать CouchDB, когда не...
- Основные 10 Причины избежать SimpleDB Hype
- Поддерживает ли CouchDB ссылочную целостность?
Я думал об этом долго и тяжело, когда дело доходит до предоставления руководства по отладке против утверждения в отношении проблем тестирования.
Вы должны иметь возможность протестировать свой класс с ошибочным вводом, плохим состоянием, недопустимым порядком операций и любым другим возможным условием ошибки, и утверждение должно никогда не отключаться. Каждое утверждение проверяет, должно ли всегда быть правдой независимо от вводимых данных или выполненных вычислений.
Хорошие правила большого пальца, к которым я пришел:
Утверждения не являются заменой надежного кода, который функционирует правильно независимо от конфигурации. Они дополняют друг друга.
Утверждения никогда не должны быть сброшены во время тестового прогона установки, даже при подаче недопустимых значений или в условиях ошибки тестирования. Код должен обрабатывать эти условия без утверждения.
При подтверждении сбоев (либо в единичном тесте, либо во время тестирования) класс прослушивается.
Для всех других ошибок - обычно вплоть до среды (сетевое соединение потеряно) или неправильного использования (вызывающий абонент передал нулевое значение) - гораздо лучше и понятнее использовать жесткие проверки и исключения. Если возникает исключение, вызывающий абонент знает, что это его вина. Если происходит утверждение, вызывающий абонент знает, что это, вероятно, ошибка в коде, где находится утверждение.
Что касается дублирования: я согласен. Я не понимаю, почему вы бы реплицировать проверку с Debug.Assert И проверки исключения. Это не только добавляет некоторый шум в код и мутит воды относительно того, кто виноват, но это форма повторения.