2009-07-09 5 views
3

Звучит как глупый вопрос с очевидным ответом :)Должны ли мы утверждать каждое создание объекта в java?

Все еще я отважился попросить вас быть вдвойне уверен.

Мы действительно с помощью утверждает, как приведено ниже

ArrayList alProperties = new ArrayList(); 

assert alProperties != null : "alProperties is null"; 

Проблема в том, что делает небольшой & простой документ, чтобы следовать, по утверждает трудно. Есть много книг по утверждениям, но в идеале я хотел бы дать новому программисту очень простые рекомендации по использованию чего-то вроде утверждений. Кстати, есть ли какой-нибудь инструмент вроде pmd для правильного использования утверждений?

Заранее спасибо.

ответ

19

Нет разумной причины использовать подобные утверждения. Если объект по какой-либо причине не будет создан, ваше утверждение даже не будет достигнуто (потому что выбрано исключение или, например, вышли VM)

+0

Если между «новым» и «утвердительным» существует много кода, который может изменять «свойства». –

+0

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

1

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

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

0

Вы хотите, чтобы ASSERTS проверяли свойства или инварианты вашей программы. Хороший документ для обучения этому должен побуждать программиста систематически или методично думать о таких свойствах.

3

это как не доверяет JVM. Что касается того, что вы принимаете в качестве заданного, вам нужно провести линию где-нибудь ...

+0

... и не доверяя себе. Во время разработки у вас должны быть тесты, чтобы рассказать вам, когда вы совершаете ошибки. Затем во время выполнения вы должны быть уверены в своем коде, который хорошо написан - если не будет доказано обратное. –

6

Есть несколько довольно кратких рекомендаций по использованию утверждений в Sun's Programming with Assertions. В этой статье утверждается, что утверждения должны использоваться для таких вещей, как Внутренние Инварианты, Инварианты Контрольного потока и Предпосылки, Постусловия и Инварианты Класса.

4

Нет, вы не хотите проверять создание объекта.

Если создание объекта завершается неудачно, jvm будет вызывать OutOfMemoryError, и если это произойдет, вы, вероятно, все равно не будете устранены.

0

Если утверждение терпит неудачу, поверьте, у вас будут большие проблемы, чем просто дело с утверждением.

Если это утверждение терпит неудачу, я думаю, что пришло время искать другую работу, потому что компьютер не ведет себя так, как это должно быть, и когда это произойдет, весь ад сломается!

3

В Java каждый вызов new возвращает либо ненулевую ссылку на новый объект, либо вызывает исключение или ошибку. В первом случае ваше утверждение верно, во втором случае утверждение не будет достигнуто, потому что вы закончите следующий соответствующий блок catch.

Это утверждение проверяет, нарушена ли ваша реализация Java, и в этом случае вы даже не можете полагаться на assert. Поэтому я бы не стал так утверждать. Используйте assert для ограничений на объекты, которые не используются языком (например, если ваш метод передан параметром, который является нулевым, но не должен быть).

3

Это утверждают только загромождает ваш код, это было бы эквивалентно этому утверждают:

boolean a = true; 
assert a : "A should be true" 

Вы не должны быть тестирование вашей виртуальной машины Java, если это не точка вашей программы (например, это набор тестов для созданный вами JVM). Вместо этого вы должны тестировать свои предварительные условия, пост-условия и инварианты. Иногда эти тесты являются слишком общими или слишком дорогими.

Предпосылки, вероятно, должны появляться только в начале метода (если у вас очень длинные методы, тогда вы должны разбить этот метод на мелкие части, даже если они все частные).

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

Инварианты также часто не могут быть протестированы, вы не можете проверить, что ваше текущее решение является правильным частичным решением (см. Ниже) - хотя это одна из приятных вещей о написании вещей с хвостовой рекурсией. Вместо этого вы объявляете инвариант комментария.

Если вы вызываете вещи извне, вы также должны использовать утверждение, например, в вашем примере, если у вас есть ArrayList.Create(), тогда вы можете выбрать подтверждение утверждения для null. Но только потому, что вы не доверяете другому коду. Если вы написали этот код, вы можете поместить это утверждение (комментарий или другое) в свой заводский метод.

int max(int[] a, int n) { 
    assert n <= a.length : "N should not exceed the bounds of the array" 
    assert n > 0 : "N should be at least one" 

    // invariant: m is the maximum of a[0..i] 
    int m = a[0]; 
    for(int i = 1; i < n; n++) { 
    if(m < a[i]) 
     m = a[i]; 
    } 

    // if these were not basic types, we might assert that we found 
    // something sensible here, such as m != null 
    return m; 
}