Re[8]: assert not for public methods - Java

Здравствуйте, devcoach, Вы писали:

D>Здравствуйте, Hard_Club, Вы писали:

H_C>>Да, просто assert в данном случае самое оно, по-моему. Мы же проверяем нарушение контракта, а не корректность входных параметров.
D>Вы неправильно трактуете публичные методы. Это не методы с сигнатурой public, а методы, с которыми работает конечный пользователь. Это большая разница. Действительно, валидировать ассертами значения, которые передал пользователь нельзя. А валидировать значения, переданные в public метод какого-то внутреннего класса можно, если существуют четкие и устоявшиеся ограничения, когда и кто его может вызывать.

О!
Теперь ясно. Но как тогда по-научному называется методы с сигнатурой public?

Здравствуйте, devcoach, Вы писали:

D>Здравствуйте, StanislavK, Вы писали:

SK>>Мое мнение, что ассерты вообще больная идея и их нельзя использовать. Проверять что-то в дебаге и не проверять потом в продакшине это... не хорошо.
D>Это вы очень зря. Ассерты по своей сути — легковесные тесты. Причем они могут проверять такие вещи, до которых тестами никогда не докопаешься. Но при этом, разумеется, валидировать ими параметры пользовательского API — не вариант. Они нужны для отслеживания работы непубличных кишок.

Не понял. Что это такое до чего тестами не докопаешься? И при чем тут вообще тесты?
Есть проверка на что-то такое, что не должно случиться и эта проверка радостно выкилывается в продакшен коде, т.е. случться жопа, а никто и не узнает. Прекрасно!

Есть хотите поспорить, то давай-те примеры и обсудим, что там лучше зделать вместо ассерта.

Здравствуйте, StanislavK, Вы писали:

SK>Не понял. Что это такое до чего тестами не докопаешься? И при чем тут вообще тесты?
Тесты тут при том, что assert'ы созданы для помощи в тестировании приложения при его разработке.

SK>Есть проверка на что-то такое, что не должно случиться и эта проверка радостно выкилывается в продакшен коде, т.е. случться жопа, а никто и не узнает. Прекрасно!
Еще раз, assert — инструмент для тестирования в момент разработки. Так же, как и обычные юнит-тесты.

SK>Есть хотите поспорить, то давай-те примеры и обсудим, что там лучше зделать вместо ассерта.
Да у меня весь проект в ассертах, и мы регулярно им говорим спасибо. Цель ассерта очень и очень проста. Есть у вас какая-то внутренняя логика. И вы знаете, что на определенном шаге в конкретном месте всегда должно выполняться определенное условие. Отлично, вы туда ставите assert. Теперь если какой-нибудь Вася, внедряя свою новую фияу, сломает это условие, он сразу же словит эксепшн, даже до того, как он написал тесты. Ведь это только в сказках бывает так, что у нас все закрыто интерфейсами, все можно оттестировать, а единороги какают радугой.
Более того, какие-то вещи в принципе нельзя достоверно оттестировать. Например, многопоточные кейсы. Если у вас есть какая-то замороченная многопоточная логика, то как вы не изголяйтесь, вы не сможете написать тест, который на 100% гарантирует вам отсутствие в коде гонок. А ассершны могут вам дегко эту уверенность увеличить.

Резюмируя:
1) assert — это инструмент для тестирования приложения на этапе разработки;
2) требует минимальных трудозатрат;
3) легко проникает в труднодоступные для классических тестов места.

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

Здравствуйте, devcoach, Вы писали:

D>Поэтому мне вообще непонятно, о чем тут спорить. Разумеется, такой удобный инструмент нужно использовать, тут даже думать не о чем.
Вопрос в том как огородить код от misuse assert-ов. Мало ли кому взбредет в голову их не по назначению использовать.

Здравствуйте, Blazkowicz, Вы писали:

B>Вопрос в том как огородить код от misuse assert-ов. Мало ли кому взбредет в голову их не по назначению использовать.
Ну это да, но выстрелить себе в ногу можно любым инструментом, assert не является исключением.

Здравствуйте, devcoach, Вы писали:

SK>>Не понял. Что это такое до чего тестами не докопаешься? И при чем тут вообще тесты?
D>Тесты тут при том, что assert'ы созданы для помощи в тестировании приложения при его разработке.
Это просто ярлык. Вседа верите на слово? Наверно были большим фанатом персистент бинов?

SK>>Есть проверка на что-то такое, что не должно случиться и эта проверка радостно выкилывается в продакшен коде, т.е. случться жопа, а никто и не узнает. Прекрасно!
D>Еще раз, assert — инструмент для тестирования в момент разработки. Так же, как и обычные юнит-тесты.
Еще раз см. выше. То, что вы это повторяете, оно не станет правдой. assert — просто бесполезная и опасная штука, которую некоторые товарищи используют для якобы тестирования. Опасная она потому, что вместо того, чтобы писать надежный код с проверками, люди начинают городить ассерты и думают, что все будет пучком.

SK>>Есть хотите поспорить, то давай-те примеры и обсудим, что там лучше зделать вместо ассерта.
D>Да у меня весь проект в ассертах, и мы регулярно им говорим спасибо. Цель ассерта очень и очень проста. Есть у вас какая-то внутренняя логика. И вы знаете, что на определенном шаге в конкретном месте всегда должно выполняться определенное условие. Отлично, вы туда ставите assert. Теперь если какой-нибудь Вася, внедряя свою новую фияу, сломает это условие, он сразу же словит эксепшн, даже до того, как он написал тесты. Ведь это только в сказках бывает так, что у нас все закрыто интерфейсами, все можно оттестировать, а единороги какают радугой.
D>Более того, какие-то вещи в принципе нельзя достоверно оттестировать. Например, многопоточные кейсы. Если у вас есть какая-то замороченная многопоточная логика, то как вы не изголяйтесь, вы не сможете написать тест, который на 100% гарантирует вам отсутствие в коде гонок. А ассершны могут вам дегко эту уверенность увеличить.
Да это бред како-то. Если у вас есть гонка, то значит получится так, что данные будут в некорректном состоянии, что значит, что надо срочно падать или, хотябы, писать о проблеме в лог, а не довольствоваться выкинутым в релизе ассертом.

D>Резюмируя:
D>1) assert — это инструмент для тестирования приложения на этапе разработки;
D>2) требует минимальных трудозатрат;
D>3) легко проникает в труднодоступные для классических тестов места.
Вы не книжку пишете. Вне контекста, это просто пустые тезисы. Давайте ограничемся примерами того, где вам кажется, что этот иструмент работает и обсудим. Пример с многопоточностью пока выглядит не очень.

D>Поэтому мне вообще непонятно, о чем тут спорить. Разумеется, такой удобный инструмент нужно использовать, тут даже думать не о чем.
О нем надо забыть и больше никода не вспоминать.

Здравствуйте, devcoach, Вы писали:

D>Вы неправильно трактуете публичные методы. Это не методы с сигнатурой public, а методы, с которыми работает конечный пользователь. Это большая разница. Действительно, валидировать ассертами значения, которые передал пользователь нельзя. А валидировать значения, переданные в public метод какого-то внутреннего класса можно, если существуют четкие и устоявшиеся ограничения, когда и кто его может вызывать.

Позволю не согласиться. С точки зрения использования assert-ов разница между public и private методами очевидна.
public метод может вызвать кто угодно и когда угодно. Поэтому его логика зависит от параметров и состояния объекта. Поэтому вместо assert-ов в них стоит использовать Runtime исключения и прочую валидацию.
private метод вызывается только другими методами этого же класса. Поэтому параметры private метода и состояние объекта в момент вызова private метода предопределены.
assert-ы помогают выявить нарушения в вызове private методов.

В целом, соглашуюсь с точкой зрения StanislavK. Практического и полезного применения assert-ов в Java пока не видел.

Checked или Unchecked исключения?

Здравствуйте, Hard_Club, Вы писали:

H_C>Checked или Unchecked исключения?
На вкус и цвет каждому свои фломастеры.

Здравствуйте, Hard_Club, Вы писали:

H_C>Checked или Unchecked исключения?
Checked исключения это всегда логика приложения.
assert никогда не должен быть логикой приложения.
Напрашивает логический вывод.

Здравствуйте, StanislavK, Вы писали:

SK>Это просто ярлык. Вседа верите на слово? Наверно были большим фанатом персистент бинов?

Понятия не имею, о чем вы.

>Еще раз см. выше. То, что вы это повторяете, оно не станет правдой. assert — просто бесполезная и опасная штука, которую некоторые товарищи используют для якобы тестирования. Опасная она потому, что вместо того, чтобы писать надежный код с проверками, люди начинают городить ассерты и думают, что все будет пучком.
Вы упорно не можете или не хотите услышать, что я пытаюсь до вас донести. Где я написал, что какие-то проверки нужно заменять ассертами? Если у вас в коде есть какая-то проверка, по итогам которой хотите бросить пользователю эксепшн, то, разумеется, ассерты использовать нельзя. В десятый раз повторяю: ассерты — это инструмент для тестирования, а не для управления реальной логикой приложения. Что такое тестирование вы понимаете? Следуя вашей выернутой наизнанку логике, я могу так же сказать: "А нафига нужны тесты вообще? Надо же просто проверку в коде, а потом эксепшн бросить!? Ведь тесты в продакшне не гоняются!" Ну конечно, они не гоняются. Их используют в процессе разработки, что бы отловить ошибки. И они точно так же, как и ассерты, не влияют на логику приложения в продакшне.

>Да это бред како-то. Если у вас есть гонка, то значит получится так, что данные будут в некорректном состоянии, что значит, что надо срочно падать или, хотябы, писать о проблеме в лог, а не довольствоваться выкинутым в релизе ассертом.
См. выше.

SK>Вы не книжку пишете. Вне контекста, это просто пустые тезисы. Давайте ограничемся примерами того, где вам кажется, что этот иструмент работает и обсудим. Пример с многопоточностью пока выглядит не очень.
Элементарнейший пример с многопоточностью. Есть какая-то заумная многопоточная логика. Есть некий метод, который можно вызывать только внутри критической секции. Если он вызван вне критической секции, то это косяк. То есть, на примере с synchronized, не сам этот метод synchronized, а он должен быть вызван внутри synchronized (надеюсь, идея понятна). Вот я написал два метода, method1() и method2(), все круто. А потом пришел Вася, и зафигачил method3(), в котором забил на синхронизацию. Не вопрос, мой ассершн сразу обрубит ему эту возможность:

public class Service {

    public void method1() {
        // ...
        synchronized (this) {
            // ...
            someNotThreadSafeLogic();
            // ...
        }
        // ...
    }

    public synchronized void method2() {
        // ...
        someNotThreadSafeLogic();
        // ...
    }

    public void method3() {
        // ...
        someNotThreadSafeLogic();
        // ...
    }

    private void someNotThreadSafeLogic() {
        assert Thread.holdsLock(this);
        // ...
    }
}

Это не валидация чего-то. Это не изменение логики программы. Это просто предохранитель, не более.

Здравствуйте, Hard_Club, Вы писали:

H_C>Checked или Unchecked исключения?
Это вопрос не простой. На вкус и цвет. Я предпочитаю Runtime по причине того, что проще и код выглядит лучше. Но про них проще забыть, не заметить... правда плохо ли это... если код написано корректно, то проблем в любом случае быть не должно.
Главное в исключениях, это то, что если исключение не просто "все кончено", то оно должно быть документированно.

B> Практического и полезного применения assert-ов в Java пока не видел.

Я видел. У нас findbugs встроен в сборку, и у него есть проверка, что код проверяет возвращаемое значение queue.offer, потому что для bounded queue там возвращается false, если элемент был отвергнут.

Для unbounded queue эта проверка бессмысленна, но findbugs об этом не знает.

"assert queue.offer" позволяет успокоить findbugs без @SuppressWarning-а, который мне не нравится

D>Это не валидация чего-то. Это не изменение логики программы. Это просто предохранитель, не более.

Хороший такой предохранитель, который кидает "AssertionError extends Error", который с 99% вероятностью пролетит мимо всех кэтчей и вырубит поток. Или у вас везде Throwable ловится?

Здравствуйте, avpavlov, Вы писали:

D>>Это не валидация чего-то. Это не изменение логики программы. Это просто предохранитель, не более.

A>Хороший такой предохранитель, который кидает "AssertionError extends Error", который с 99% вероятностью пролетит мимо всех кэтчей и вырубит поток. Или у вас везде Throwable ловится?

Вы тоже читать не умеете?

Что я писал выше по поводу того, когда работают ассершны? В продакшне, или во время девелопмента?

Здравствуйте, devcoach, Вы писали:

D>Здравствуйте, StanislavK, Вы писали:

>>Еще раз см. выше. То, что вы это повторяете, оно не станет правдой. assert — просто бесполезная и опасная штука, которую некоторые товарищи используют для якобы тестирования. Опасная она потому, что вместо того, чтобы писать надежный код с проверками, люди начинают городить ассерты и думают, что все будет пучком.
D>Вы упорно не можете или не хотите услышать, что я пытаюсь до вас донести. Где я написал, что какие-то проверки нужно заменять ассертами? Если у вас в коде есть какая-то проверка, по итогам которой хотите бросить пользователю эксепшн, то, разумеется, ассерты использовать нельзя.
При чем тут пользователь? Ему плевать на ваши исключения. По поводу того, что проверки заменять ассертами — вы только об этом и пишете. И пример тоже об это. Например там есть проверка на то, что "пришел Вася, и зафигачил method3(), в котором забил на синхронизацию.", которую вы считаете почему-то не важной для продакшина, но достаточно важной для тестирования.

> В десятый раз повторяю: ассерты — это инструмент для тестирования, а не для управления реальной логикой приложения. Что такое тестирование вы понимаете? Следуя вашей выернутой наизнанку логике, я могу так же сказать: "А нафига нужны тесты вообще? Надо же просто проверку в коде, а потом эксепшн бросить!? Ведь тесты в продакшне не гоняются!" Ну конечно, они не гоняются. Их используют в процессе разработки, что бы отловить ошибки. И они точно так же, как и ассерты, не влияют на логику приложения в продакшне.
Для тестирования — тесты, а не ассерты. Эксепшн бросится точно так и в тесте и в продакшене, что просто замечательно.

>>Да это бред како-то. Если у вас есть гонка, то значит получится так, что данные будут в некорректном состоянии, что значит, что надо срочно падать или, хотябы, писать о проблеме в лог, а не довольствоваться выкинутым в релизе ассертом.
D>См. выше.
Что смотреть? То, что вы игнорировать проблемы в продашн коде?

SK>>Вы не книжку пишете. Вне контекста, это просто пустые тезисы. Давайте ограничемся примерами того, где вам кажется, что этот иструмент работает и обсудим. Пример с многопоточностью пока выглядит не очень.
D>Элементарнейший пример с многопоточностью. Есть какая-то заумная многопоточная логика. Есть некий метод, который можно вызывать только внутри критической секции. Если он вызван вне критической секции, то это косяк. То есть, на примере с synchronized, не сам этот метод synchronized, а он должен быть вызван внутри synchronized (надеюсь, идея понятна). Вот я написал два метода, method1() и method2(), все круто. А потом пришел Вася, и зафигачил method3(), в котором забил на синхронизацию. Не вопрос, мой ассершн сразу обрубит ему эту возможность:
Там должен быть не ассершн, а нормальный эксепшн, которы точно так же обрубит эту возможноть, причем не только в тестах.

D>Это не валидация чего-то. Это не изменение логики программы. Это просто предохранитель, не более.
"Предохранитель" для тестов. "Ха" два раза. Предохранители они не для тестов.

Здравствуйте, devcoach, Вы писали:

D>Здравствуйте, avpavlov, Вы писали:

D>>>Это не валидация чего-то. Это не изменение логики программы. Это просто предохранитель, не более.

A>>Хороший такой предохранитель, который кидает "AssertionError extends Error", который с 99% вероятностью пролетит мимо всех кэтчей и вырубит поток. Или у вас везде Throwable ловится?

D>Вы тоже читать не умеете?

Что я писал выше по поводу того, когда работают ассершны? В продакшне, или во время девелопмента?

Тогда возвращаемся туда, где СтаниславК писал тебе, что проверки должны быть всегда, потому что никакое тестирование не идёт в сравнение с богатством вариантов использования в продакшн

Здравствуйте, StanislavK, Вы писали:

SK>При чем тут пользователь? Ему плевать на ваши исключения. По поводу того, что проверки заменять ассертами — вы только об этом и пишете. И пример тоже об это. Например там есть проверка на то, что "пришел Вася, и зафигачил method3(), в котором забил на синхронизацию.", которую вы считаете почему-то не важной для продакшина, но достаточно важной для тестирования.
Два момента.
1) Почитайте на досуге JavaDoc к методу Thread.holdsLock(), а то позоритесь.
2) У вас какая-то извращенная логика касательно важности. Здесь речь идет не о том, что это "не важно для продакшна", а о том, что это до продакшна никогда не должно дойти в принципе. Что такое баг, знаете? Ну это когда программа работает некорректно. Релизить продукт с багами плохо, потому все стремятся минимизировать их количество. И когда баг находят, то есть два принципиально разных варианта зафиксить его: добавить каких-нибудь дополнительных проверок, что бы до места с багом выполнение не дошло, или же устранить причину бага. Как именно поступать — зависит от специфики конкретного участка кода. Если это публичный код, то обычно надо обрубить юзеру возможность делать запрещенные вещи. А если это ваш внутренний код, то надо устранить причину бага, а не проверки городить и эксепшны бросать, а потом обезопасить себя тестами. Так и вижу прям, как вы из кишков своего кода, когда не прошла валидация какой-нибудь вашей же внутренней переменной, бросаете юзеру эксепшн с общим смыслов "Не удалось выполнить операцию, так как наши разработчики из внутреннего метода А, про который вы ничего не знаете, передали в метод В, про который вы тоже ничего не знаете, некорретный аргумент C, про который вы также ничего не знаете."

Пользователь, наверняка, обрадуется такому эксепшну.

SK>Для тестирования — тесты, а не ассерты. Эксепшн бросится точно так и в тесте и в продакшене, что просто замечательно.
Для тестирования и тесты и ассерты. Собственно, тест это обычно и есть набор ассертов, просто вынесенных в отдельный тестовый класс.

SK>Там должен быть не ассершн, а нормальный эксепшн, которы точно так же обрубит эту возможноть, причем не только в тестах.
Ну это опять таки к вопросу про JavaDoc к методу Thread.holdsLock().

D>Вы тоже читать не умеете?

Что я писал выше по поводу того, когда работают ассершны? В продакшне, или во время девелопмента?

А ExecutorService зачем тогда?

Здравствуйте, Hard_Club, Вы писали:

D>>Вы тоже читать не умеете?

Что я писал выше по поводу того, когда работают ассершны? В продакшне, или во время девелопмента?
H_C>А ExecutorService зачем тогда?
Это как связано?

А ExecutorService зачем тогда?

D>1) Почитайте на досуге JavaDoc к методу Thread.holdsLock(), а то позоритесь.

И? В Яве за историю существования столько ошибочных решений было, что нет смысла принимать javadoc за истину в последней инстанции.

Метод Thread.holdsLock() — очевидный костыль, который в новом ConcurrencyAPI исправили добавлением методов Lock.tryLock/ReentrantLock.isLocked

Здравствуйте, devcoach, Вы писали:

D>Здравствуйте, StanislavK, Вы писали:

SK>>При чем тут пользователь? Ему плевать на ваши исключения. По поводу того, что проверки заменять ассертами — вы только об этом и пишете. И пример тоже об это. Например там есть проверка на то, что "пришел Вася, и зафигачил method3(), в котором забил на синхронизацию.", которую вы считаете почему-то не важной для продакшина, но достаточно важной для тестирования.
D>Два момента.
D>1) Почитайте на досуге JavaDoc к методу Thread.holdsLock(), а то позоритесь.
Поясните, плз.

D>2) У вас какая-то извращенная логика касательно важности. Здесь речь идет не о том, что это "не важно для продакшна", а о том, что это до продакшна никогда не должно дойти в принципе. Что такое баг, знаете? Ну это когда программа работает некорректно. Релизить продукт с багами плохо, потому все стремятся минимизировать их количество. И когда баг находят, то есть два принципиально разных варианта зафиксить его: добавить каких-нибудь дополнительных проверок, что бы до места с багом выполнение не дошло, или же устранить причину бага. Как именно поступать — зависит от специфики конкретного участка кода. Если это публичный код, то обычно надо обрубить юзеру возможность делать запрещенные вещи. А если это ваш внутренний код, то надо устранить причину бага, а не проверки городить и эксепшны бросать, а потом обезопасить себя тестами. Так и вижу прям, как вы из кишков своего кода, когда не прошла валидация какой-нибудь вашей же внутренней переменной, бросаете юзеру эксепшн с общим смыслов "Не удалось выполнить операцию, так как наши разработчики из внутреннего метода А, про который вы ничего не знаете, передали в метод В, про который вы тоже ничего не знаете, некорретный аргумент C, про который вы также ничего не знаете."

Пользователь, наверняка, обрадуется такому эксепшну.
Кто вам сказал, что пользователю надо показывать исключения? Если на то пошло, то пользователю ничего кроме "Извините мы упали" ничего показывать нельзя. Но это другой вопрос. Исключения надо в логи писать.
Проблема в том, что баги случаются на продакшине и глупо лишаться возможности их там заприметить. Если вы поставили ассерт, значит честно думаете, что в этом месте что-то может пойти не так. Но только почему-то думаете, что оно обязательно пойдет не так на тестах и вы все конечно же там все отловите. Извините, но так думать глупо.
Еще хороший вопрос — если что-то пойдет на продакжине не так, то как вы об этом узнате если уберете проверки?

SK>>Для тестирования — тесты, а не ассерты. Эксепшн бросится точно так и в тесте и в продакшене, что просто замечательно.
D>Для тестирования и тесты и ассерты. Собственно, тест это обычно и есть набор ассертов, просто вынесенных в отдельный тестовый класс.

SK>>Там должен быть не ассершн, а нормальный эксепшн, которы точно так же обрубит эту возможноть, причем не только в тестах.
D>Ну это опять таки к вопросу про JavaDoc к методу Thread.holdsLock().
Вам не стоит JavaDoc воспринемать настолько буквально. Слава богу там не было написано "убиться об стену".

H_C>А ExecutorService зачем тогда?

А он не везде используется. И если для своего кода ты можешь сделать его использование обязательным, то для библиотечного — нет.

Здравствуйте, avpavlov, Вы писали:

A>И? В Яве за историю существования столько ошибочных решений было, что нет смысла принимать javadoc за истину в последней инстанции.

Ну почитайте тогда JavaDoc к более "новому" методу ReentrantLock.isHeldByCurrentThread(), если вас Thread.holdsLock() не устраивает.

A>Метод Thread.holdsLock() — очевидный костыль, который в новом ConcurrencyAPI исправили добавлением методов Lock.tryLock/ReentrantLock.isLocked
Вы это на полном серьезе пишете, или стебетесь? Костыль к чему? Исправили что? Для чего вообще нужен ReentrantLock, и в чем его преимущества и недостатки перед synchronized знаете? Объясняю по пунктам:
1) Писать многопоточный код сложно.
2) Не менее сложно его тестировать.
3) ... поэтому разработчики Java любезно предоставили нам вспомогателные средства для дебага. Thread.holdsLock(), ReentrantLock.isHeldByCurrentThread() + куча подобных методов во всех синхронайзерах из пакета j.u.c..
4) Это не костыли к чему-либо, так как они ничего не исправляют и ни на что не влияют.
5) Как я уже написал выше, аналогом Thread.holdsLock() является ReentrantLock.isHeldByCurrentThread().
6) Метод же ReentrantLock.isLocked() так же является дебаговым, но показывает совершенно другое: что лок в принципе кем-то залокирован, а не текущим тредом, как это делает ReentrantLock.isHeldByCurrentThread(). То есть isLocked() не "исправляет" isHeldByCurrentThread(). Это вообще два разных метода, которые друг другу перпендикулярны.
7) Как можно "исправить" synchronized методом Lock.tryLock() я вообще не понимаю. tryLock() это дополнительная фича, а не "исправление". Более того, при большом желании аналогичный трюк можно проделать и с synchronized, см. Unsafe.tryMonitorEnter().

Здравствуйте, StanislavK, Вы писали:

SK>Проблема в том, что баги случаются на продакшине и глупо лишаться возможности их там заприметить.
Ну тогда. следуя вашей логике, тесты писать не надо. Ну а чо, тесты же никто в продакшне не запускает, лишаемся возможности отловить баг! Даешь проверки каждой доступной переменной после каждой строчки кода

SK>Если вы поставили ассерт, значит честно думаете, что в этом месте что-то может пойти не так. Но только почему-то думаете, что оно обязательно пойдет не так на тестах и вы все конечно же там все отловите. Извините, но так думать глупо.
Нет. Когда я ставлю assert, то я говорю не "здесь что-то может пойти не так", а "здесь всегда должно идти так". А если что-то "пошло не так", значит это баг, и мой продукт неработоспособен. А если он неработоспособен, то никакие проверки меня не спасут.

SK>Еще хороший вопрос — если что-то пойдет на продакжине не так, то как вы об этом узнате если уберете проверки?
Еще раз, я нигде не призывал менять что-то на assert. Я лишь говорил о том, что добавление асершнов позволяет улучшить качество кода. Не замена, а добавление.

H_C>Checked или Unchecked исключения?

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

имхо это прежде всего про коммуникацию между программистами,
поэтому странно использовать checked между двумя своими классами (ибо код превращается черти во что без особой необходимости), а вот в библиотечных классах для коммуникации с (неизвестными) клиентами — нужно

А почему Unchecked делают код таким прямо ужасным?

D>Вы это на полном серьезе пишете, или стебетесь? Костыль к чему? Исправили что? Для чего вообще нужен ReentrantLock, и в чем его преимущества и недостатки перед synchronized знаете? Объясняю по пунктам:

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

D>6) Метод же ReentrantLock.isLocked() так же является дебаговым, но показывает совершенно другое: что лок в принципе кем-то залокирован, а не текущим тредом, как это делает ReentrantLock.isHeldByCurrentThread(). То есть isLocked() не "исправляет" isHeldByCurrentThread(). Это вообще два разных метода, которые друг другу перпендикулярны.

Сам приписал мне высказывание ("То есть isLocked() не "исправляет" isHeldByCurrentThread()"), сам опроверг. Молодец.

D>7) Как можно "исправить" synchronized методом Lock.tryLock() я вообще не понимаю. tryLock() это дополнительная фича, а не "исправление". Более того, при большом желании аналогичный трюк можно проделать и с synchronized, см. Unsafe.tryMonitorEnter().

Не передёргивай, я не писал, что synchronized испорчен и требует исправлениф. "Испорчено" было АПИ, которое не давало возможности контролировать локи в полной мере.

D>Для чего вообще нужен ReentrantLock, и в чем его преимущества и недостатки перед synchronized знаете? Объясняю по пунктам:

Пункты-то когда будут? Всё что ты написал, к сравнению ReentrantLock и synchronized относится чуть менее чем никак

EE>поэтому странно использовать checked между двумя своими классами (ибо код превращается черти во что без особой необходимости), а вот в библиотечных классах для коммуникации с (неизвестными) клиентами — нужно

Хороши как средство борьбы с возвращаемыми null значениями, в расчёте, что кто-то где-то не забудет проверить на нулл и обработать как надо. Checked исключение очень эффективно тут.

Правда, в последнее время всякие findbugs-ы научились хорошо работать с @Nullable/@Nonnull и чекед исключения опять слегка стали ненужны.

Здравствуйте, devcoach, Вы писали:

D>Здравствуйте, StanislavK, Вы писали:

SK>>Проблема в том, что баги случаются на продакшине и глупо лишаться возможности их там заприметить.
D>Ну тогда. следуя вашей логике, тесты писать не надо. Ну а чо, тесты же никто в продакшне не запускает, лишаемся возможности отловить баг! Даешь проверки каждой доступной переменной после каждой строчки кода

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

SK>>Если вы поставили ассерт, значит честно думаете, что в этом месте что-то может пойти не так. Но только почему-то думаете, что оно обязательно пойдет не так на тестах и вы все конечно же там все отловите. Извините, но так думать глупо.
D>Нет. Когда я ставлю assert, то я говорю не "здесь что-то может пойти не так", а "здесь всегда должно идти так". А если что-то "пошло не так", значит это баг, и мой продукт неработоспособен. А если он неработоспособен, то никакие проверки меня не спасут.
Полностью не спасут, полностью ничего не спасет, но если будет нормальная проверка, она поможет идентифицировать проблему.

SK>>Еще хороший вопрос — если что-то пойдет на продакжине не так, то как вы об этом узнате если уберете проверки?
D>Еще раз, я нигде не призывал менять что-то на assert. Я лишь говорил о том, что добавление асершнов позволяет улучшить качество кода. Не замена, а добавление.
Как так? Вы же сами предлагаете вместо:

if ( !Thread.holdsLock(this) ) {
    throw new RuntimeException("Ops, method called without lock! We can't guarantee that application can continue to work properly");
}

писать:

assert Thread.holdsLock(this)

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

Здравствуйте, avpavlov, Вы писали:

A>До 1.4 ты не мог узнать залочен объект или нет — очевидный косяк (в том же .Net это было сразу). В 1.4 добавили костыль, а в 1.5 — уже нормальное АПИ, которое предоставляло полный контроль над поведением программы. Например, получать лок не дольше какого-то времени, и при неудаче переходить к другой ветке программы.
Хорошо, но как это относится к чисто дебаговым методам ReentrantLock.isLocked(), ReentrantLock.isHeldByCurrentThread() и Thread.holdsLock()? До 1.5 конкарренси вообще не особо то работало в Java. volatile реордерились, j.u.c вообще отсутствовал. Но какое это имеет отношение к теме топика?

A>Не передёргивай, я не писал, что synchronized испорчен и требует исправлениф. "Испорчено" было АПИ, которое не давало возможности контролировать локи в полной мере.
Как именно оно было испорчено?

Здравствуйте, StanislavK, Вы писали:

SK>Почему это? По моей логике тесты писать надо, но они просто по-определению никогда не отловят все баги. Баги будут всегда и везде, даже в продакшине.
С этим никто и не спорит.

SK>Полностью не спасут, полностью ничего не спасет, но если будет нормальная проверка, она поможет идентифицировать проблему.
Повторюсь. Проблемы бывают разные. Есть проблемы "внешние", про которые надо сказать юзеру, что бы он принял на основе этого какое-то решение. Например, юзер передал некорректный аргумент, с которым ваша библиотека не будет работать. А есть проблемы "внутренние", которые сигнализируют о баге в коде. И в случае таких проблем, все уже не так очевидно.

SK>Как так? Вы же сами предлагаете вместо:

SK>

SK>if ( !Thread.holdsLock(this) ) {
SK>    throw new RuntimeException("Ops, method called without lock! We can't guarantee that application can continue to work properly");
SK>}
SK>

SK>писать:

SK>

SK>assert Thread.holdsLock(this)
SK>

SK>по-мне, так это просто выглядит этаким мазохизмом — знать, что тут можеть что-то пойти не так, но проверку выкинуть. Наверно, чтобы веселее было потом продакшин отлаживать.
Э нее, я такого не предлагал. Я нигде не предлагал "вместо". Я лишь показал пример использования ассрешна, когда где-то в потрохах моего кода, в private методе стоит проверка что я использую свой же код корректно. Не юзер использует мой код, а я сам. Что мне даст этот эксепшн? Сообщит юзеру о том, что в системе баг? Сообщит юзеру, что мой продукт неработоспособен?

Здравствуйте, devcoach, Вы писали:

D>Здравствуйте, StanislavK, Вы писали:

SK>>Полностью не спасут, полностью ничего не спасет, но если будет нормальная проверка, она поможет идентифицировать проблему.
D>Повторюсь. Проблемы бывают разные. Есть проблемы "внешние", про которые надо сказать юзеру, что бы он принял на основе этого какое-то решение. Например, юзер передал некорректный аргумент, с которым ваша библиотека не будет работать. А есть проблемы "внутренние", которые сигнализируют о баге в коде. И в случае таких проблем, все уже не так очевидно.
И что? О чем вообще это фраза? Вы хотите сказать, что "внутренние" ошибки надо игнорировать? И, вообще, при чем тут пользователь?

SK>>по-мне, так это просто выглядит этаким мазохизмом — знать, что тут можеть что-то пойти не так, но проверку выкинуть. Наверно, чтобы веселее было потом продакшин отлаживать.
D>Э нее, я такого не предлагал. Я нигде не предлагал "вместо". Я лишь показал пример использования ассрешна, когда где-то в потрохах моего кода, в private методе стоит проверка что я использую свой же код корректно. Не юзер использует мой код, а я сам. Что мне даст этот эксепшн? Сообщит юзеру о том, что в системе баг? Сообщит юзеру, что мой продукт неработоспособен?
То, что это даст — во-первых не будет исполняться код, который уже не может гарантировать корректное исполнение, во-вотрых, не знаю как там у вас с этим, но у нормальных людей такие исключения будут сохранены в логе, по которому потом можно будет уже разобраться, что и где случилось.
Юзер же, кем бы он ни был, должен молучть отлуп, так как система в этой ситуации уже не способна выдать корректный ответ. Худшее, что можно сделать в это ситуации, это продолжать работать как ни в чем не бывало, т.к. система после этого будет в неопределенном состоянии.

H_C>А почему Unchecked делают код таким прямо ужасным?

не unchecked, а checked,
потому что при _каждом_ вызове метода, который выбрасывает этот checked нужно будет думать, что с этим исключением делать, либо в сигнатуру метода добавлять (что захламляет сигнатуру опять же без надобности особой), либо в try catch оборачивать, что сильно ухудшает читабельность

D>Что мне даст этот эксепшн? Сообщит юзеру о том, что в системе баг? Сообщит юзеру, что мой продукт неработоспособен?

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

Здравствуйте, StanislavK, Вы писали:

SK>Здравствуйте, Hard_Club, Вы писали:

H_C>>Недавно прочитал в одной книге, что с помощью assert нельля проверять аргументы в публичных методах, т.к. его можно оключить, а public-методы должны всегда проверять входящие параметры. Откуда взялось такое правило? Кто его установил?

SK>Мое мнение, что ассерты вообще больная идея и их нельзя использовать. Проверять что-то в дебаге и не проверять потом в продакшине это... не хорошо.

assert-ы это инструмент. С удобным красивым синтаксисом и понятной целью. То, что их можно отключать, не значит, что их нужно отключать. Если считаете, что доход от раннего обнаружения возможного бага превышает доход от снижения нагрузки из-а включенных assert-ов, естественно их надо включать.

Здравствуйте, devcoach, Вы писали:

__>У меня складывается впечатление, что devcoach на самом деле никогда не сталкивался с проблемами реального продакшина, выездом к клиентам, командировкам за тысячи километров на промышленные предприятия с расписанным по минутам посещением и необходимостью решить проблему "еще вчера" и т.п.
__>Все что тут пишется смахивает на рассуждения офисного девелопера, в поля не ходящего, бегающих в панике пользователей не успокаивающего и вообще живущего в несколько тепличных условиях.
__>Поддерживаю идею неприятия ассертов. Если программа может работать из-за чего-то неправильно — это стечение обстоятельств обязательно когда-то произойдет (и как назло именно у клиента, в продакшене) и это надо проверить/зажурнализировать/..., коль скоро вообще возникла мысль это контролировать.
__>Своим сотрудникам настрого запретил использовать ассерты под страхом лишения премии
D>Жалко ваших сотрудников, не могут пользоваться нормальными устоявшимися практиками из-за бзиков начальства. Ну а вообще, я уже давал рекомендации выше для таких случаев — раз вы запретили ассерты, то обязательно запретите и тесты. Ибо тесты, так же как и ассерты, не гоняются в продакшне. Вместо этого, после каждой строчки кода проверяйте, что все текущие переменные не перешли в невалидное состояние. Если все же перешли, то бросайте BugInCodeException, и журналируйте его использует мой код, а я сам. Что мне даст этот эксепшн? Сообщит юзеру о том, что в системе баг? Сообщит юзеру, что мой продукт неработоспособен?

Я не понимаю, почему делается какая-то зависимость тестов от ассертов.

Я вообще по вашим словам не понимаю, как вы и компания в которой вы работаете разрабатываете и поддерживаете свое ПО.

Тесты (автоматические, в частности юнит) по большому счету нужны, чтобы понимать, что при очередной ночной сборке не отвалилось что-то из того, что работало определенным образом ранее.
Они позволяют сохранить устойчивое поведение системы. К наличию или отсутствию ассертов не имеет никакого отношения.
На продакшн данных они конечно, как правило не гоняются, но на продакшн энвайронменте — сколько угодно.

Я не понимаю вашей идеи в фразе про "сообщить юзеру, что продукт неработоспособен".
Есть куча ситуаций, когда в продакшене в принципе не может быть такого, что продукт "встанет", потому что разработчик не знал что в этом случае делать.
Если ПО поведет себя так — считайте что вы потеряли клиента, "попали на деньги" и т.п. Продукт должен выживать как можно дольше, хватаясь за любую возможность продолжить работать и ассерты тут как раз будут мешать.

Это как преславутая ситуация с бортовым ПО одного истребителя. Когда там случилось некое переполнение — цифровое управление не нашло ничего лучше, как выставить рули управления в крайнее положение, из-за чего самолет тупо пошел в пике и пилоты еле смогли катапультироваться. Разработчики просто не обработали эту ситуацию, посчитав, что такого не может быть. Вот и тут так же.

Здравствуйте, _newcomer_, Вы писали:

__>Я не понимаю, почему делается какая-то зависимость тестов от ассертов.
Потому что assert в нетестовом коде — это продолжение assert-ов в юнит тестах. Я уже не знаю, как еще объянсить, что assert-ы и юнит тесты — это две взаимосвязанные сущности, вернее — это вообще одно и тоже, просто в разных местах проекта.

__>Я вообще по вашим словам не понимаю, как вы и компания в которой вы работаете разрабатываете и поддерживаете свое ПО.
Если вы про качество, то это:
1) Code review;
2) Тесты (юнит + ассерты);
3) QA отдел;
4) Поддержка пользователей.

Здравствуйте, devcoach, Вы писали:

__>>Я не понимаю, почему делается какая-то зависимость тестов от ассертов.
D>Потому что assert в нетестовом коде — это продолжение assert-ов в юнит тестах. Я уже не знаю, как еще объянсить, что assert-ы и юнит тесты — это две взаимосвязанные сущности, вернее — это вообще одно и тоже, просто в разных местах проекта.

Вот эти ваши утверждения и вызывают недоумение.
Такое впечатление что мы о разных вещах говорим.

Ассерты в юниттестах лишь способ продиагностировать поведение/состояние системы во время прогонки тестов на какой-либо конфигурации ПО.
По сути это попытка эмулировать прохождение по разным сценариям развития событий.
Сам код подопытной системы работает как и должен работать. Мы никак не вмешиваемся в его поведение.
Для самом системы никаких юнит тестов как бы и нет.

Ассерты же в коде подопытной системы, которые тут как раз некоторым (и мне) не нравятся — это вмешивание
в логику работы системы непредсказуемыми потенциальными перенаправлениями управления. Причем код,
который находится после ассерта, в случае разработки, выполнен не будет — и это вполне может устроить
разработчика, но в продакшене в этом месте должна быть корректная реакция в виде корректного
продолжения работы без падений/необработанных исключения и т.п. А если произошло что-то действительно,
требующее внимания разработчика — это должно попасть в лог с максимумом информации о нештатной
ситуации. И соответственно, раз об этом задумались (о такой реакции в этом месте), то этот код все равно
писать и нафига тут тогда вообще ассерт если мы и так ситуацию обработали?

Скажите, чего я не понимаю?

__>>Я вообще по вашим словам не понимаю, как вы и компания в которой вы работаете разрабатываете и поддерживаете свое ПО.
D>Если вы про качество, то это:
D>1) Code review;
D>2) Тесты (юнит + ассерты);
D>3) QA отдел;
D>4) Поддержка пользователей.

Из какой области это ПО, сколько пользователей и какие последствия падения ПО с неработоспособностью хотя бы один час?

Здравствуйте, _newcomer_, Вы писали:

__>Ассерты же в коде подопытной системы, которые тут как раз некоторым (и мне) не нравятся — это вмешивание
__>в логику работы системы непредсказуемыми потенциальными перенаправлениями управления. Причем код,
__>который находится после ассерта, в случае разработки, выполнен не будет — и это вполне может устроить
__>разработчика, но в продакшене в этом месте должна быть корректная реакция в виде корректного
__>продолжения работы без падений/необработанных исключения и т.п. А если произошло что-то действительно,
__>требующее внимания разработчика — это должно попасть в лог с максимумом информации о нештатной
__>ситуации. И соответственно, раз об этом задумались (о такой реакции в этом месте), то этот код все равно
__>писать и нафига тут тогда вообще ассерт если мы и так ситуацию обработали?

__>Скажите, чего я не понимаю?
Вы не понимаете, что assert не является вмешиванием в логику работы системы. Они работают только на этапе девелопмента. По сути — это те же тесты, только более легковесные, и вынесенные из тестового модуля в сам код. По сути, assert является "активным комментарием", который показывает разработчику, в каком состоянии должна быть система на определенном этапе, а так же способствуют раннему обнаружению багов. Не пользователю показывает, а разработчику. В продакшене же ассрты должны быть отключены. Не могут быть отключены, а должны быть отключены. Так же, как и "отключены" (если так можно выразиться) тесты.
Короче говоря, это просто дополнительный инструмент тестирования, который никак не влияет на логику приложения в продакшне.

Вот еще один примерчик использования ассертов:

public class Service {         
    public void publicMethod1(Object arg1, Object arg2) {
        if (arg1 == null)
            throw new IllegalArgumentException("arg1 cannot be null.");

        if (arg2 == null)
            throw new IllegalArgumentException("arg2 cannot be null.");
        
        // ...
        commonPrivateMethod(arg1, arg2);
        // ...
    }
    
    public void publicMethod2(Object arg1) {
        if (arg1 == null)
            throw new IllegalArgumentException("arg1 cannot be null.");
        
        //...
        Object internalObject = ...
        //...
        commonPrivateMethod(arg1, internalObject);
        //...
    } 
    
    private void commonPrivateMethod(Object arg1, Object arg2) {
        assert arg1 != null;
        assert arg2 != null;
        
        // ...
    }
}

То есть у нас два публичных метода. Мы там все валидируем, бросаем эксепшны, все как надо. А есть один общий приватный метод, который вызывается где-то из кишок, и в него должны прийти уже отвалидированные данные. Что, мне там заново вызывать эту валидацию? Дублировать код? А если это достаточно тяжелая валидация? Мне второй раз ее вызывать в продакшне? Нет, я просто ассертну эти аргументы и все. Никакого дублирования кода, просто лишний хинт разработчику, в каком состоянии должна быть система в этом месте.

Здравствуйте, devcoach, Вы писали:

D>Здравствуйте, StanislavK, Вы писали:

SK>>Мое мнение, что ассерты вообще больная идея и их нельзя использовать. Проверять что-то в дебаге и не проверять потом в продакшине это... не хорошо.
D>Это вы очень зря. Ассерты по своей сути — легковесные тесты. Причем они могут проверять такие вещи, до которых тестами никогда не докопаешься. Но при этом, разумеется, валидировать ими параметры пользовательского API — не вариант. Они нужны для отслеживания работы непубличных кишок.

вход во "внутренние кишки" проходит через внешние методы, параметры в которых у вас проверяются юнит-тестами.
Если вы ставите assert во внутреннем методе, то вы либо не знаете как он используется, либо у вас это аналог TODO, чтобы проверить этот участок кода позже.
К тому же есть еще человеческий фактор: люди могут тупо отключить assert-ы и забыть включить.
к примеру у себя сталкиваюсь периодически с тем, что код комитится без прогона всех тестов

В итоге получаем лишний способ сделать себе больно.
Многопоточный код который вы приводите в качестве примера вообще очень странная вещь: может начать срабатывать только выше определенной нагрузки, которая на тестовом сервере не воспроизведется, а всплывет именно 31 декабря вечером на продакшене

Здравствуйте, devcoach, Вы писали:

D>Здравствуйте, _newcomer_, Вы писали:

D>Вы не понимаете, что assert не является вмешиванием в логику работы системы.
D>Короче говоря, это просто дополнительный инструмент тестирования, который никак не влияет на логику приложения в продакшне.
Что у вас это так, все поняли, что все понять не могуть это какой с этом смысл и кому это надо в таком виде.

D>Вот еще один примерчик использования ассертов:
D>

D>public class Service {         
D>    public void publicMethod1(Object arg1, Object arg2) {
D>        if (arg1 == null)
D>            throw new IllegalArgumentException("arg1 cannot be null.");

D>        if (arg2 == null)
D>            throw new IllegalArgumentException("arg2 cannot be null.");
        
D>        // ...
D>        commonPrivateMethod(arg1, arg2);
D>        // ...
D>    }
    
D>    public void publicMethod2(Object arg1) {
D>        if (arg1 == null)
D>            throw new IllegalArgumentException("arg1 cannot be null.");
        
D>        //...
D>        Object internalObject = ...
D>        //...
D>        commonPrivateMethod(arg1, internalObject);
D>        //...
D>    } 
    
D>    private void commonPrivateMethod(Object arg1, Object arg2) {
D>        assert arg1 != null;
D>        assert arg2 != null;
        
D>        // ...
D>    }
D>}
D>

D>То есть у нас два публичных метода. Мы там все валидируем, бросаем эксепшны, все как надо. А есть один общий приватный метод, который вызывается где-то из кишок, и в него должны прийти уже отвалидированные данные. Что, мне там заново вызывать эту валидацию? Дублировать код? А если это достаточно тяжелая валидация? Мне второй раз ее вызывать в продакшне? Нет, я просто ассертну эти аргументы и все. Никакого дублирования кода, просто лишний хинт разработчику, в каком состоянии должна быть система в этом месте.

Почему не вызывать второй раз? В чем проблема?
Насчет, дублирование кода, вообще не понял. В вашем примере код вполне дублируется. То, что вы что-то выразили другим синтаксисом, это не значит, что дублирования нет. У вас там все те же проверки, только вместо того, чтобы их везде делать одинаково, вы решили, что простым быть не модно, надо те же проверки делать по-разному, в зависимотри от модификатора на методе...

Здравствуйте, vsb, Вы писали:

H_C>>>Недавно прочитал в одной книге, что с помощью assert нельля проверять аргументы в публичных методах, т.к. его можно оключить, а public-методы должны всегда проверять входящие параметры. Откуда взялось такое правило? Кто его установил?
SK>>Мое мнение, что ассерты вообще больная идея и их нельзя использовать. Проверять что-то в дебаге и не проверять потом в продакшине это... не хорошо.
vsb>assert-ы это инструмент. С удобным красивым синтаксисом и понятной целью. То, что их можно отключать, не значит, что их нужно отключать. Если считаете, что доход от раннего обнаружения возможного бага превышает доход от снижения нагрузки из-а включенных assert-ов, естественно их надо включать.

Еще один. Может тогда расскажете про цель и про красивый синтаксис? Только без повторений "devcoach"-а, плз, не поленитесь прочитать ветку.
И не надо про нагрузку, что-бы сказать, что что-то где-то замедляет, это надо доказать, причем для конкретного случае.

Здравствуйте, tavr, Вы писали:

T>вход во "внутренние кишки" проходит через внешние методы, параметры в которых у вас проверяются юнит-тестами.
Это в идеальном мире. Реальность же совсем другая. Во-первых, тесты сами могут некорректными. Во-вторых нет гарантии 100% покрытия тестами конкретно сейчас. В-третьих, код склонен меняться: сегодня у вас метод используется в двух местах, и они закрыты тестами. А завтра его наспех за час до релиза впендюрили в третье место, и не оттестировали. Во всех этих ситуациях ассерт вам поможет.

T>Если вы ставите assert во внутреннем методе, то вы либо не знаете как он используется, либо у вас это аналог TODO, чтобы проверить этот участок кода позже.
Это не TODO. И да, я не знаю, как у меня будут использоваться внутренние методы в будущем. Сегодня в двух местах, завтра Вася их вставит еще в 10 мест.

T>К тому же есть еще человеческий фактор: люди могут тупо отключить assert-ы и забыть включить.
На вашем тестовом сервере включили ассерты один раз, и забыли про это навсегда.

T>к примеру у себя сталкиваюсь периодически с тем, что код комитится без прогона всех тестов

С этим ничего не поделать.

T>В итоге получаем лишний способ сделать себе больно.
Чтобы сделать себе ассертами больно, надо не уметь ими пользоваться. Например, писать логику, которая полагается на AssertionError и просить пользователя запускать ваше приложение в продакшне с -ea. Но такое встречается редко, и, как вы понимаете, это вине не ассерта, а недостаточно квалифицированного инженера. А сделать себе больно можно любым инструментом.

T>Многопоточный код который вы приводите в качестве примера вообще очень странная вещь: может начать срабатывать только выше определенной нагрузки, которая на тестовом сервере не воспроизведется, а всплывет именно 31 декабря вечером на продакшене

Нет, к нагрузке он вообще никакого отношения не имеет. Метод либо вызвали внутри synchronized, либо нет. Это даже в однопоточном тесте мгновенно всплывет с вероятностью 100%.

Здравствуйте, StanislavK, Вы писали:

SK>Почему не вызывать второй раз? В чем проблема?
Зачем дважды вызывать одно и то же? Про DRY слышали? А с перформанс проблемами когда-нибудь сталкивались? То, что хорошо в девелопменте, не всегда хорошо в продакшне, ваш кэп.

SK>Насчет, дублирование кода, вообще не понял. В вашем примере код вполне дублируется. То, что вы что-то выразили другим синтаксисом, это не значит, что дублирования нет. У вас там все те же проверки, только вместо того, чтобы их везде делать одинаково, вы решили, что простым быть не модно, надо те же проверки делать по-разному, в зависимотри от модификатора на методе...
Эээ, нее, это не дублирование кода. Это тест внутри кода, да. Это "активный комментарий" внутри кода, да. Но это ни в коем случае не повторение логики из публичного метода. Хотя бы потому, что эта "повторяющаяся логика", как вы говорите, не будет вызвана в продакшне.

Здравствуйте, StanislavK, Вы писали:

SK>И не надо про нагрузку, что-бы сказать, что что-то где-то замедляет, это надо доказать, причем для конкретного случае.
Вот это ваше утверждение есть ни что иное, как непонимание классической мудрости "premature optimization is root of all evil". Тут дело вот в чем.
Дилетант считает, что premature optimziation — это любая оптимизация кода, которая сделана до того, как в этом месте появилась проблема с перфомансом.
Опытный же программист знает, что premature optimziation — это оптимизация кода, которая сделана до того, как в этом месте появилась проблема с перфомансом И на эту оптимизацию было затрачено много усилий. Что такое "много" — зависит от контекста конкретной задачи.

Поэтому, если я знаю, что я уже вроде как все отвалидировал в паблик методах, то я не буду это валидировать еще 100500 раз в своих внутренных методах. Вместо этого я просто поставлю внутри ассерт, и все. Формально это "оптимизация", так как в продакшне вмеcто 100500 + 1 раз валидация будет вызвана 1 раз. Но это ни в коем случае не "premature optimization", так как я не затратил на это сил. Я ничего не рефакторил, не делал новые тикеты, не писал никакие дополнительные тесты, и т.д. Я просто следовал здравому смыслу, потратив на это 1 минуту своего времени.

Здравствуйте, devcoach, Вы писали:

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

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

Но это — НЕ ТАК!
И в этом суть нашего с вами разногласия.

Ваше тестовое покрытие не 100%
Вы не можете эмулировать на 100% нагрузку и ситуации в боевой эксплуатации.
У вас просто нет тех данных и обстоятельств, которые еще может только сложатся через полгода, после запуска системы/новой версии.

По этому то, что вы считаете "из ряда вон выходящим стечением параметров/значений/объектов" — в реальной жизни может
случиться вполне спокойно. Причем порой вовсе не из-за логики вашей программы, а по ряду внешних причин, на
которые вы вообще никак не влияете и предвидеть не можете.

Но прекрасно осознаете, что параметры неверные и при них надо вести себя по особенному.
И если ассерты включены — вы бросите исключение, которое непонятно кто обработает.
А если отключены, то приведете систему скорее всего в неработоспособное состояние, возможно
тоже с каким-то другим исключением.

D>...Что, мне там заново вызывать эту валидацию? Дублировать код? А если это достаточно тяжелая валидация? Мне второй раз ее вызывать в продакшне?

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

И возникают еще вопросы:
1. Как вы себе представляете работу продакшена, если вы вдруг не отловили всех ситуаций, приводящих к срабатыванию ассерта при разработке/тестировании?
2. Т.к. мы исходим из того, что ассерты в продакшене отключены (как вы сами сказали), как вы гарантируете то, что все разработчики в вашем проекте проверили входные параметры заранее и в конкретном месте "ну вот точно на 146% ничего проверять не надо"?
3. Какие есть механизмы в вашем ПО, позволяющие ловить в продакшене такие "проскочившие" ассерты, которых "ну никак не должно было быть"?
4. Сколько человек у вас работает над одним проектом?

Здравствуйте, StanislavK, Вы писали:

SK>Еще один. Может тогда расскажете про цель и про красивый синтаксис? Только без повторений "devcoach"-а, плз, не поленитесь прочитать ветку.

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

Красивый синтаксис — про него можно прочитать в любом учебнике.

SK>И не надо про нагрузку, что-бы сказать, что что-то где-то замедляет, это надо доказать, причем для конкретного случае.

Ну очевидно, что замедляет. Любая лишняя машинная команда замедляет выполнение, что тут доказывать. Если проверки сложные, может и ощутимо замедлять. Кому то это важно, кому то нет. Можно отключать выборочно для классов. Отличный инструмент, гибкий и удобный, что тут ещё можно сказать.

Здравствуйте, vsb, Вы писали:

vsb>Цель — проверять инварианты и убивать приложение как можно раньше при их нарушении, чтобы предотвратить дальнейшее некорректное поведение и упростить поиск бага.

Вы в своем уме?
Или вы студент, пишущий учебные приложения или бесполезный софт под андроид?
Какой нахрен убивать приложение? Мы о продакшене и промышленном ПО говорим от которого сотни и тысячи людей, выходящих каждый день на работу, на заводы, зависят?
Приложение должно жить в идеале бесконечно, при любых обстоятельствах, иначе "приедут дяди из службы безопасности заказчика и убьют вас".

vsb>Ну очевидно, что замедляет. Любая лишняя машинная команда замедляет выполнение, что тут доказывать. Если проверки сложные, может и ощутимо замедлять. Кому то это важно, кому то нет. Можно отключать выборочно для классов. Отличный инструмент, гибкий и удобный, что тут ещё можно сказать.

Софт вначале должен работать и приносить прибыль (в том или ином виде) пользователю, а уже потом, если действительно где-то есть недостаточный перфоманс, надо оптимизировать.
Это я не к тому, что нужно сортировки пузырьком вначале писать, а к тому что оптимизация — не сама цель.

Здравствуйте, _newcomer_, Вы писали:

vsb>>Цель — проверять инварианты и убивать приложение как можно раньше при их нарушении, чтобы предотвратить дальнейшее некорректное поведение и упростить поиск бага.

__>Вы в своем уме?
__>Или вы студент, пишущий учебные приложения или бесполезный софт под андроид?
__>Какой нахрен убивать приложение? Мы о продакшене и промышленном ПО говорим от которого сотни и тысячи людей, выходящих каждый день на работу, на заводы, зависят?

Поэтому приложение, которое ведёт себя неправильно, должно умереть как можно быстрее. По крайней мере та его часть, которая может перезапуститься с чистого листа. Иначе оно испортит файлы, БД, выдаст неверный диагноз, отпилит голову рабочему.

__>Приложение должно жить в идеале бесконечно, при любых обстоятельствах, иначе "приедут дяди из службы безопасности заказчика и убьют вас".

Приложение может выбросить ошибку в любой точке. Например из-за out of memory. Если ваши системы перестают обслуживать людей из-за out-of-memory, это неправильно. Есть много способов перезапускать приложение или thread или задачу при возникновении ошибок.

vsb>>Ну очевидно, что замедляет. Любая лишняя машинная команда замедляет выполнение, что тут доказывать. Если проверки сложные, может и ощутимо замедлять. Кому то это важно, кому то нет. Можно отключать выборочно для классов. Отличный инструмент, гибкий и удобный, что тут ещё можно сказать.

__>Софт вначале должен работать и приносить прибыль (в том или ином виде) пользователю, а уже потом, если действительно где-то есть недостаточный перфоманс, надо оптимизировать.
__>Это я не к тому, что нужно сортировки пузырьком вначале писать, а к тому что оптимизация — не сама цель.

Если софт не будет работать с минимальными требованиями к производительности, никакого начала работы и прибыли не будет. Предмета спора не вижу. Я не говорю, что надо все ассерты отключать. Я говорю, что если их захочется отключить, это сделать проще, чем идти по коду и комментировать их.

Здравствуйте, devcoach, Вы писали:

Вы противоречите сами себе

D>...А завтра его наспех за час до релиза впендюрили в третье место, и не оттестировали. Во всех этих ситуациях ассерт вам поможет.

Как вам помогут отключенные в продакшене ассерты от такого неправильного использования?
Вы как раз и получите непроверенные параметры в своей функции, которая рассчитывала, что их "ну никак не может быть".
И ваш продакшен накроется медным тазом.

D>Это не TODO. И да, я не знаю, как у меня будут использоваться внутренние методы в будущем. Сегодня в двух местах, завтра Вася их вставит еще в 10 мест.

И?
Продолжите мысль, что будет тогда в продакшене с отключенными ассертами?

D>Чтобы сделать себе ассертами больно, надо не уметь ими пользоваться. Например, писать логику, которая полагается на AssertionError

Ну зачем же. Достаточно, исходя из описанного вами, иметь в команде хотя бы одного разработчика, который понятия не имел,
что перед вызовом вашей функции нужно проверить 100500 параметров, которые нужны вам там внутри и вы это чекаете через ассерты,
а ему было невдомек, потому что лично ему они нафиг не уперлись и вам он их только пробрасывает.

Здравствуйте, _newcomer_, Вы писали:

__>Ваше тестовое покрытие не 100%
__>Вы не можете эмулировать на 100% нагрузку и ситуации в боевой эксплуатации.
__>У вас просто нет тех данных и обстоятельств, которые еще может только сложатся через полгода, после запуска системы/новой версии.
Да. И что?

__>По этому то, что вы считаете "из ряда вон выходящим стечением параметров/значений/объектов" — в реальной жизни может
__>случиться вполне спокойно. Причем порой вовсе не из-за логики вашей программы, а по ряду внешних причин, на
__>которые вы вообще никак не влияете и предвидеть не можете.
Да. И что?

__>Но прекрасно осознаете, что параметры неверные и при них надо вести себя по особенному.
__>И если ассерты включены — вы бросите исключение, которое непонятно кто обработает.
Ассерты в продакшне выключены всегда. Если у вашего клиента они включены — посоветуйте их выключить.

__>А если отключены, то приведете систему скорее всего в неработоспособное состояние, возможно
__>тоже с каким-то другим исключением.
Да, это называет баг. Баги всегда переводят системы в непонятное состояние.

__>Зачем делать тяжелые валидации параметров во внешних функциях, если параметры реально нужны во внутренней, пусть там и валидируются.
Кто вам сказал, что они нужны ТОЛЬКО во внутренней? Это просто пример, когда есть обычная валидация для пользователя, а есть внутренняя валидация внутреннего метода для разработчика.

__>Есть и другие способы "оптимизации" таких проверок, но без конкретного примера обсуждать смысла нет. Приведенный пример не годится.
Да вам все не годиться

Извините, у меня NDA, рабочий код выкладывать не буду. Я вам показываю идеи, как надо использовать assert. Нравятся вам они или нет — дело третье.

__>1. Как вы себе представляете работу продакшена, если вы вдруг не отловили всех ситуаций, приводящих к срабатыванию ассерта при разработке/тестировании?
Так же, как если я не покрыл свой код на 100% тестами (а 100% покрытия, как мы знаем, не бывает никогда).

__>2. Т.к. мы исходим из того, что ассерты в продакшене отключены (как вы сами сказали), как вы гарантируете то, что все разработчики в вашем проекте проверили входные параметры заранее и в конкретном месте "ну вот точно на 146% ничего проверять не надо"?
Юнит тесты. Покрыли они валидации тестами на 10% процентов, значит я уверен на 10% + дополнительная помощь от ассертов. Покрыли на 99%, значит я уверен на 99% + дополнительная помощь от ассертов.

__>3. Какие есть механизмы в вашем ПО, позволяющие ловить в продакшене такие "проскочившие" ассерты, которых "ну никак не должно было быть"?
Никаких. Ассерты в продакшне отключены, это аксиома. Более того, они отключены по дефолту. Если кто-то добавил -ea при старте JVMки, это не мои проблемы. Так же, как не мои проблемы, если он не выделил достаточно памяти, Так же, как не мои проблемы, что он использует неподходящий GC. Так же, как не мои проблемы, что он включил какой-нибудь PrintCompilation. И т.д. Надеюсь, идея понятна.

__>4. Сколько человек у вас работает над одним проектом?
Двузначная цифра.

Здравствуйте, vsb, Вы писали:

vsb>Здравствуйте, _newcomer_, Вы писали:
__>>Вы в своем уме?
__>>Или вы студент, пишущий учебные приложения или бесполезный софт под андроид?
__>>Какой нахрен убивать приложение? Мы о продакшене и промышленном ПО говорим от которого сотни и тысячи людей, выходящих каждый день на работу, на заводы, зависят?

vsb>Поэтому приложение, которое ведёт себя неправильно, должно умереть как можно быстрее. По крайней мере та его часть, которая может перезапуститься с чистого листа. Иначе оно испортит файлы, БД, выдаст неверный диагноз, отпилит голову рабочему.

__>>Приложение должно жить в идеале бесконечно, при любых обстоятельствах, иначе "приедут дяди из службы безопасности заказчика и убьют вас".

vsb>Приложение может выбросить ошибку в любой точке. Например из-за out of memory. Если ваши системы перестают обслуживать людей из-за out-of-memory, это неправильно. Есть много способов перезапускать приложение или thread или задачу при возникновении ошибок.

Давайте не будем валить в одну кучу OutOfMemory и непроверенные параметры функций из-за отключенных ассертов.
devcoach предлагает использовать их повсеместно и, как следствие, поведение системы будет непредсказуемым в куче мест.

И даже если что-то идет совсем "не так" приложение должно выдать вразумительное диагностическое сообщение, являющееся руководством к действию для пользователя/администратора.
Как вы собираетесь подробно информировать пользователей (и разработчика через лог) о случившемся, если полагаетесь на ассерты и перезапуск приложения по каждому чиху?

Здравствуйте, _newcomer_, Вы писали:

__>>>Вы в своем уме?
__>>>Или вы студент, пишущий учебные приложения или бесполезный софт под андроид?
__>>>Какой нахрен убивать приложение? Мы о продакшене и промышленном ПО говорим от которого сотни и тысячи людей, выходящих каждый день на работу, на заводы, зависят?

vsb>>Поэтому приложение, которое ведёт себя неправильно, должно умереть как можно быстрее. По крайней мере та его часть, которая может перезапуститься с чистого листа. Иначе оно испортит файлы, БД, выдаст неверный диагноз, отпилит голову рабочему.

__>>>Приложение должно жить в идеале бесконечно, при любых обстоятельствах, иначе "приедут дяди из службы безопасности заказчика и убьют вас".

vsb>>Приложение может выбросить ошибку в любой точке. Например из-за out of memory. Если ваши системы перестают обслуживать людей из-за out-of-memory, это неправильно. Есть много способов перезапускать приложение или thread или задачу при возникновении ошибок.

__>Давайте не будем валить в одну кучу OutOfMemory и непроверенные параметры функций из-за отключенных ассертов.
__>devcoach предлагает использовать их повсеместно и, как следствие, поведение системы будет непредсказуемым в куче мест.

Я знаю про две разные позиции в этом споре. Одни хотят отключать все проверки и уповать, что даже если что-то пойдёт не так, авось кривая вывезет и нормально будет продолжать работать. На самом деле надежда не тщетная, многие программы так работают и вроде обычно всё нормально, кривая вывозит, в джаве это тем более работает, т.к. память сложно испортить и целый класс undefined behaviour исчезает. Но я всё равно считаю, что приложение или его кусок должен умирать как можно быстрее при обнаружении неверного функционирования. Естественно, если это нужно, оно должно перезапускаться тут же, необслуженные запросы должны продолжать обслуживаться и т.д. Это всё реализуемо. Если мы говорим про web app, например, достаточно просто выйти из метода сервлета, залоггировав все доступные данные для анализа, а там app server поймает исключение, проигнорирует его и продолжит выполнять следующие запросы.

__>И даже если что-то идет совсем "не так" приложение должно выдать вразумительное диагностическое сообщение, являющееся руководством к действию для пользователя/администратора.

Вразумительное диагностическое сообщение это "в программе обнаружен баг, обратитесь к разработчикам, приложив содержимое папки logs".

__>Как вы собираетесь подробно информировать пользователей (и разработчика через лог) о случившемся, если полагаетесь на ассерты и перезапуск приложения по каждому чиху?

Не понял вопроса и замечания про каждый чих. Сработал assert — вылетает Error, его ловим в нужном месте, логгируем и кидаем дальше или завершаем выполнение. По каждому чиху они не должны срабатывать в нормально написанном приложении, потому что это прямая индикация бага.

Здравствуйте, devcoach, Вы писали:

D>Здравствуйте, StanislavK, Вы писали:

SK>>И не надо про нагрузку, что-бы сказать, что что-то где-то замедляет, это надо доказать, причем для конкретного случае.
D>Вот это ваше утверждение есть ни что иное, как непонимание классической мудрости "premature optimization is root of all evil". Тут дело вот в чем.
Ах вот оно...

D>Дилетант считает, что premature optimziation — это любая оптимизация кода, которая сделана до того, как в этом месте появилась проблема с перфомансом.
Да, есть я нами, дилетантами такая проблема... все потому, что книжкам мало верим.

D>Опытный же программист знает, что premature optimziation — это оптимизация кода, которая сделана до того, как в этом месте появилась проблема с перфомансом И на эту оптимизацию было затрачено много усилий. Что такое "много" — зависит от контекста конкретной задачи.
Вот тут я ничего не понял. Это к чему? Хотя нет, понял. Просто вместо того, чтобы говорить о том, о чем я, гораздо проще подменить понятия и поговорить об определених, ну и заодно вспомнить какие все вокруг делетанты... Если все же прочитать то, что я написал — там не слова про "premature optimization". Я про то, что не надо говорить о перформансе вне контекста. Не надо утверждать, что что-то чего-то там замедляет без указания _конкретного_ случая и влияния этого _конкретного_ случая на приложение.

D>Поэтому, если я знаю, что я уже вроде как все отвалидировал в паблик методах, то я не буду это валидировать еще 100500 раз в своих внутренных методах. Вместо этого я просто поставлю внутри ассерт, и все. Формально это "оптимизация", так как в продакшне вмеcто 100500 + 1 раз валидация будет вызвана 1 раз. Но это ни в коем случае не "premature optimization", так как я не затратил на это сил. Я ничего не рефакторил, не делал новые тикеты, не писал никакие дополнительные тесты, и т.д. Я просто следовал здравому смыслу, потратив на это 1 минуту своего времени.

Как вам уже говорили — лучше валидировать, тем более, что все равно валидируете. Как к этой рекомендации отнестись — ваще дело. К счастью, не думаю, что мне придется поддерживать вашу систему...

Здравствуйте, devcoach, Вы писали:

D>Никаких .... Так же, как не мои проблемы, если он ...

Я это изначально и предполагал

Как видно, вы не несете никакой ответственности перед заказчиком руководством, так что проблемы продакшена от вас далеки.
На этом считаю и надо закончить разговор.

Здравствуйте, devcoach, Вы писали:

D>Здравствуйте, StanislavK, Вы писали:

SK>>Почему не вызывать второй раз? В чем проблема?
D>Зачем дважды вызывать одно и то же? Про DRY слышали? А с перформанс проблемами когда-нибудь сталкивались? То, что хорошо в девелопменте, не всегда хорошо в продакшне, ваш кэп.
Куда нам... у нас весь перфоманс параметры валидирует

SK>>Насчет, дублирование кода, вообще не понял. В вашем примере код вполне дублируется. То, что вы что-то выразили другим синтаксисом, это не значит, что дублирования нет. У вас там все те же проверки, только вместо того, чтобы их везде делать одинаково, вы решили, что простым быть не модно, надо те же проверки делать по-разному, в зависимотри от модификатора на методе...
D>Эээ, нее, это не дублирование кода. Это тест внутри кода, да. Это "активный комментарий" внутри кода, да. Но это ни в коем случае не повторение логики из публичного метода. Хотя бы потому, что эта "повторяющаяся логика", как вы говорите, не будет вызвана в продакшне.

В вашем примере явное дублирование. Давайте другой пример, обсудим.

Здравствуйте, _newcomer_, Вы писали:

__>Как вам помогут отключенные в продакшене ассерты от такого неправильного использования?
__>Вы как раз и получите непроверенные параметры в своей функции, которая рассчитывала, что их "ну никак не может быть".
__>И ваш продакшен накроется медным тазом.
Никакого противоречия нет. У меня есть билд сервер, который при каждом комите/сборке гоняет тесты. Разумеется, на нем выставлен -ea. Если я хреново покрыл тестами новую логику, и у меня нет ассертов, то мне никто не поможет. Если же у меня есть ассерты в каком-то общем внутреннем методе, то они могут оказать мне дополнительную помощь. А могут и не оказать. Но уж точно не повредят.

__>Продолжите мысль, что будет тогда в продакшене с отключенными ассертами?
То же, что будет в продакшне с отлюченными тестами — ничего страшного.

__>зачем же. Достаточно, исходя из описанного вами, иметь в команде хотя бы одного разработчика, который понятия не имел,
__>что перед вызовом вашей функции нужно проверить 100500 параметров, которые нужны вам там внутри и вы это чекаете через ассерты,
__>а ему было невдомек, потому что лично ему они нафиг не уперлись и вам он их только пробрасывает.
Во-первых, есть описание задачи. Во-вторых, есть code review. В-третьих, есть юнит-тесты. Он хорошо покрыл свою задачю юнит-тестами — они свалились, он добавил явные недостающие явные проверки. Он плохо покрыл свою задачу юнит-тестами — они не свалились, но может быть помогут ассерты.
Неправильное выполнение задачи программистом — не повод 100500 раз дублировать код.

Здравствуйте, vsb, Вы писали:

vsb>Я знаю про две разные позиции в этом споре.

Предлагаю внимательно перечитать топик "по ролям" и кто, что предлагал.

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

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

И основной моей мыслью было, что его упование на нахождение багов при разработке — ошибочно.
А отключение ассертов приводит к "само вывезет", что недопустимо.

Здравствуйте, devcoach, Вы писали:

Напомню вам, что я выступаю за отказ от использования ассертов вообще, в пользу явных проверок и реагирования.
Мне без разницы, включены они в продакшене или нет, так как по мне их вообще быть не должно.
А то складывается впечатление, что вы забили с чем спорите.

D>Никакого противоречия нет. У меня есть билд сервер, который при каждом комите/сборке гоняет тесты. Разумеется, на нем выставлен -ea. Если я хреново покрыл тестами новую логику, и у меня нет ассертов, то мне никто не поможет. Если же у меня есть ассерты в каком-то общем внутреннем методе, то они могут оказать мне дополнительную помощь. А могут и не оказать. Но уж точно не повредят.

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

D>Во-первых, есть описание задачи. Во-вторых, есть code review. В-третьих, есть юнит-тесты. Он хорошо покрыл свою задачю юнит-тестами — они свалились, он добавил явные недостающие явные проверки. Он плохо покрыл свою задачу юнит-тестами — они не свалились, но может быть помогут ассерты.
D>Неправильное выполнение задачи программистом — не повод 100500 раз дублировать код.

Вы когда говорите, такой впечатление, что не в реальном мире девелопментом занимаетесь, а начитались книжек и из них умные мысли высказываете.
Или еще студент. Бррр.....

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

Здравствуйте, vsb, Вы писали:

SK>>Еще один. Может тогда расскажете про цель и про красивый синтаксис? Только без повторений "devcoach"-а, плз, не поленитесь прочитать ветку.
vsb>Цель — проверять инварианты и убивать приложение как можно раньше при их нарушении, чтобы предотвратить дальнейшее некорректное поведение и упростить поиск бага.
Да вы что? И правда, ни один "if" с таким не справится, надо срочно ассерты делать.

vsb>Красивый синтаксис — про него можно прочитать в любом учебнике.
не знаю, не читал. Вообще не красиво отсылать к таким источникам. Мы тут все, я надеюсь, взрослые люди. Просто поясните, что вы имели ввиду. Я немного удивлен данным утверждением, так как это примерно то же что сказать, что у "if" красивый синтаксис. Сказать это, конечно можно, но звучит странно...
Насчет того, насколько assert удобен для отлова ошибок, вообще — он не позволяет добавить никакой информации, кроме самого условия, что его делает менее полезным при отдадке проблем, чем нормальные проверки.

SK>>И не надо про нагрузку, что-бы сказать, что что-то где-то замедляет, это надо доказать, причем для конкретного случае.
vsb>Ну очевидно, что замедляет. Любая лишняя машинная команда замедляет выполнение, что тут доказывать.
Если так подходить к перфомансу, то ява не для вас. Пишите на на чем-то без gc и vm оверхедов. Они отъедают гораздо больше, чем проверка на null.

vsb>Если проверки сложные, может и ощутимо замедлять. Кому то это важно, кому то нет. Можно отключать выборочно для классов.
Все правда.

vsb>Отличный инструмент, гибкий и удобный, что тут ещё можно сказать.
Проверка, сама по-себе, да отличный инструмент, но assert — в баню.

On 10.01.2014 13:25, _newcomer_ wrote:
> D>Никаких .... Так же, как не мои проблемы, если он ...
>
> Я это изначально и предполагал
> Как видно, вы не несете никакой ответственности перед заказчиком
> руководством, так что проблемы продакшена от вас далеки.

Мил человек, а ты кто такой-то сам, безотносительно к обсуждаемой
тематике? Хоть название фирмы озвучь, где работаешь. А то тут и
командировки к заказчикам уже прозвучали, и персональная ответственность
и "служба безопасности приедет, всех убьёт" и заводы остановятся и небо
на землю рухнет. И всё из-за какого-то чудака, который зачем-то запустит
приложение с -ea, проигнорировав даденные ему инструкции. Какой-то прям
1C-франчайзи-стайл, интересно что за софт вы разрабатываете такой.

--
WBR,
Serge.

P.S. Ассерты сам не использую, хотя определённые резоны в этом вижу.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, _newcomer_, Вы писали:

vsb>>Я знаю про две разные позиции в этом споре.

__>StanislavK и я высказывались за неиспользование ассертов, т.к. "поведение должно быть одинаковым и при разработке и в продакшене", а с отключаемыми ассертами в продакшене это не так.

Ну очевидно это не может быть так вообще. Есть такие понятия как debug сборка и release сборка. Есть обфускаторы. Никогда не будет одинаковым поведение в разработке и в продакшне.

__>Кроме того, если их не отключать, то это как раз упование на "само вывезет", что недопустимо в промышленных системах.

Почему?

__>Если ты предполагаешь что тут может быть проблема = обработай ее явно, а не кидай исключение, которое никто не перехватит.

Почему никто не перехватит? Кто это запрещает?

__>devcoach же предлагал повсеместно "правильно" использовать ассерты, отключая их в продакшене. Якобы ассерты позволяют ему тестировать приложения, находя баги.

Тестировать приложение ассерты очевидно помогают. Заменять ассерт на if (!cond) throw MyAssertException("cond is false") можно, но это уродливо и глупо смотрится. Идею с выключением всех ассертов в продакшне я не поддерживаю. Если это очень сильно надо и без этого никак, можно и отключить.

__>И основной моей мыслью было, что его упование на нахождение багов при разработке — ошибочно.
__>А отключение ассертов приводит к "само вывезет", что недопустимо.

Не знаю, допустимо или не допустимо, ошибочно или не ошибочно, в разных проектах разные требования. Но мне вариант с отключением ассертов не нравится.

Здравствуйте, hrensgory, Вы писали:

H>Мил человек, а ты кто такой-то сам, безотносительно к обсуждаемой
H>тематике? Хоть название фирмы озвучь, где работаешь. А то тут и
H>командировки к заказчикам уже прозвучали, и персональная ответственность
H>и "служба безопасности приедет, всех убьёт" и заводы остановятся и небо
H>на землю рухнет.

Озвучивать название не буду, не зачем.
Заказчиков много из российской промышленности (сотни предприятий).
И крупные и мелкие. Командировки по всей стране от Калининграда до Владивостока.
Есть немного клиентов и за рубежом. В бизнесе более 15 лет. Не 1С.

H>И всё из-за какого-то чудака, который зачем-то запустит
H>приложение с -ea, проигнорировав даденные ему инструкции.

Вы хотите быть еще одним, кто "книгу не читал, но осуждаю"?
Перечитайте еще раз, о чем говорил я. Мне без разницы, включены
ассерты или нет. Мое мнение — в промышленной системе их быть не должно.
и не потому что они отключены в продакшене, а потому что разработчики
должны обрабатывать все явно.

Здравствуйте, StanislavK, Вы писали:

SK>>>Еще один. Может тогда расскажете про цель и про красивый синтаксис? Только без повторений "devcoach"-а, плз, не поленитесь прочитать ветку.
vsb>>Цель — проверять инварианты и убивать приложение как можно раньше при их нарушении, чтобы предотвратить дальнейшее некорректное поведение и упростить поиск бага.
SK>Да вы что? И правда, ни один "if" с таким не справится, надо срочно ассерты делать.

В приложении много if-ов. Разные if-ы служат разным целям. А assert служит вполне конкретной цели и при чтении кода assert помогает понять быстрее, для чего он тут нужен. Так можно и for выкинуть и do-while, одного while хватит всем. Был бы goto, можно было бы и while выкинуть, есть же if, чего тут разводить зоопарк, в самом деле.

vsb>>Красивый синтаксис — про него можно прочитать в любом учебнике.
SK>не знаю, не читал. Вообще не красиво отсылать к таким источникам. Мы тут все, я надеюсь, взрослые люди. Просто поясните, что вы имели ввиду. Я немного удивлен данным утверждением, так как это примерно то же что сказать, что у "if" красивый синтаксис. Сказать это, конечно можно, но звучит странно...

Я тогда не понял вопрос.

assert x == y; выглядит очевидно красивее, понятнее и читабельнее, чем if (!(x == y)) { throw new MyAssertionException("Assertion x == y failed"); }

SK>Насчет того, насколько assert удобен для отлова ошибок, вообще — он не позволяет добавить никакой информации, кроме самого условия, что его делает менее полезным при отдадке проблем, чем нормальные проверки.

Информация добавляется вторым аргументом, если надо. То, что он не добавляет само условие в текстовом виде это да, неудобно, но номера строки в принципе хватает, чтобы понять, о чём идёт речь.

SK>>>И не надо про нагрузку, что-бы сказать, что что-то где-то замедляет, это надо доказать, причем для конкретного случае.
vsb>>Ну очевидно, что замедляет. Любая лишняя машинная команда замедляет выполнение, что тут доказывать.
SK>Если так подходить к перфомансу, то ява не для вас. Пишите на на чем-то без gc и vm оверхедов. Они отъедают гораздо больше, чем проверка на null.

Java во многих местах используется и имеет достаточно хорошую производительность, чтобы её почти всегда хватало. Если это короткий цикл с математикой на 10 минут, там пара лишних сравнений может дать замедление на процент-другой и отключить assertions в этом цикле, считая, что он хорошо протестирован, проще, чем переписывать его на С или ассемблере.

vsb>>Отличный инструмент, гибкий и удобный, что тут ещё можно сказать.
SK>Проверка, сама по-себе, да отличный инструмент, но assert — в баню.

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

Так в у test framework есть же еще свои ассерты. Можно спользовать их в тестах, а в коде — нативные

Здравствуйте, vsb, Вы писали:

vsb>Ну очевидно это не может быть так вообще. Есть такие понятия как debug сборка и release сборка. Есть обфускаторы. Никогда не будет одинаковым поведение в разработке и в продакшне.

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

__>>Кроме того, если их не отключать, то это как раз упование на "само вывезет", что недопустимо в промышленных системах.
vsb>Почему?

Потому что пока в этой теме их никто не собирался явно ловить.

__>>Если ты предполагаешь что тут может быть проблема = обработай ее явно, а не кидай исключение, которое никто не перехватит.
vsb>Почему никто не перехватит? Кто это запрещает?

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

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

vsb>Заменять ассерт на if (!cond) throw MyAssertException("cond is false") можно, но это уродливо и глупо смотрится.

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

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

Здравствуйте, _newcomer_, Вы писали:

__>Здравствуйте, hrensgory, Вы писали:

__>Мое мнение — в промышленной системе их быть не должно. и не потому что они отключены в продакшене, а потому что разработчики должны обрабатывать все явно.
Да да да, все потенциальные баги надо обрабатывать явно. Я уже дал рецепт для такой ситуации:
1) Вам необходимо выпилить все тесты, ибо разработчики должны все обрабатывать явно, а не полагаться на что-то, что не запускается в рподакшне;
2) Введите в своей команде правило: после каждой полезной строчки кода должны идти проверки всех видимых из данного участка переменных на все возможные невалидные состояния.

On 10.01.2014 14:26, _newcomer_ wrote:

> Озвучивать название не буду, не зачем.

Ну как это незачем, вы же наезжаете на оппонента, причём довольно
невежливым образом — то он у вас студент и книжек начитался, то вы не
поймёте что за хрень у них с процессами, строго спрашиваете "Из какой
области это ПО, сколько пользователей и какие последствия падения ПО с
неработоспособностью хотя бы один час?", "Сколько человек у вас работает
над одним проектом?" Вот и вызывает интерес персона ткзть вопрошающего.

> Заказчиков много из российской промышленности (сотни предприятий).
> И крупные и мелкие. Командировки по всей стране от Калининграда до
> Владивостока.
> Есть немного клиентов и за рубежом. В бизнесе более 15 лет. Не 1С.

Это неконкретно всё, не отвечает на действительно интересный вопрос о
том, что за софт вы такой разрабатываете на яве, что исповедуете столь
радикальные взгляды и прям готовы головой своей и другими частями тела
за него перед заказчиком лично ответить. Согласитесь, нечасто такое
встретишь в мире лицензий типа the software is provided "as-is". Ну и
ваша роль в этом процессе интересна — вы девелопер, лид, ПМ, ЛПР?

> H>И всё из-за какого-то чудака, который зачем-то запустит
> H>приложение с -ea, проигнорировав даденные ему инструкции.
>
> Вы хотите быть еще одним, кто "книгу не читал, но осуждаю"?
> Перечитайте еще раз, о чем говорил я. Мне без разницы, включены
> ассерты или нет. Мое мнение — в промышленной системе их быть не должно.
> и не потому что они отключены в продакшене, а потому что разработчики
> должны обрабатывать все явно.

Звучит просто прекрасно ) Но в анонимной подаче как-то малоубедительно,
нужен какой-нибудь пример крупного продукта на яве, разработанного вашей
компанией где "разработчики обработали всё явно". Ну, чтоб на него
равняться.

--
WBR,
Serge.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, hrensgory, Вы писали:

H>On 10.01.2014 14:26, _newcomer_ wrote:

>> Озвучивать название не буду, не зачем.
H>Ну как это незачем, вы же наезжаете на оппонента, причём довольно
H>невежливым образом

А, т.е. вы вступились за честь другого, так сказать, защищаете тех,
кого на ваш взгляд обижают? Интересно интересно

H>Это неконкретно всё, не отвечает на действительно интересный вопрос о
H>том, что за софт вы такой разрабатываете на яве

Софт не только на Джава, но и на других языках. И серверное и клиентское ПО.
И мобильные и десктопные и веб-приложения.

H>Согласитесь, нечасто такое встретишь в мире лицензий типа the
H>software is provided "as-is".

А кто вам сказал какая у нашего софта лицензия?
В общем случае проприетарное ПО за приличные деньги.

H>Ну и ваша роль в этом процессе интересна — вы девелопер, лид, ПМ, ЛПР?

Ну проектов много, где-то ПМ, где-то лид.

Какое это все отношение к обсуждаемой теме ассертов имее?

H>Звучит просто прекрасно ) Но в анонимной подаче как-то малоубедительно,
H>нужен какой-нибудь пример крупного продукта на яве, разработанного вашей
H>компанией где "разработчики обработали всё явно". Ну, чтоб на него
H>равняться.

Не вижу смысла вас в чем-то убеждать.
Вижу что вас "возмутил" этот спор и вы решили добавить веса в нем одной из сторон своими обратными наездами и переходом на личности.
Ваше право — к обсуждаемой теме отношения не имеет.

Вы напоминаете деревенского забияку, в разгаре спора вскакивающего с фразой "...а ты кто вообще такой?...".
Забавно

On 10.01.2014 15:38, _newcomer_ wrote:
>>> Озвучивать название не буду, не зачем.
> H>Ну как это незачем, вы же наезжаете на оппонента, причём довольно
> H>невежливым образом
>
> А, т.е. вы вступились за честь другого, так сказать, защищаете тех,
> кого на ваш взгляд обижают? Интересно интересно

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

> А кто вам сказал какая у нашего софта лицензия?
> В общем случае проприетарное ПО за приличные деньги.

Если вы своими деньгами прямо отвечаете за убытки заказчиков, которые
являются результатом действия или бездействия вашего ПО, то это достойно
удивления. И даже, честно сказать, с трудом в это верится без конкретных
фактов-то. Максимум на что хватает моей фантазии — это то, что вы может
быть подписываетесь на бесплатную техподдержку и штрафы за невыполнение SLA.

> H>Ну и ваша роль в этом процессе интересна — вы девелопер, лид, ПМ, ЛПР?
>
> Ну проектов много, где-то ПМ, где-то лид.
>
> Какое это все отношение к обсуждаемой теме ассертов имее?

Самое прямое. Вы вообще на яве-то, извиняюсь, пишете?

> Вы напоминаете деревенского забияку, в разгаре спора вскакивающего с
> фразой "...а ты кто вообще такой?...".

Ну я так понял названий-то не будет?

--
WBR,
Serge.

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, hrensgory, Вы писали:

H>Если вы своими деньгами прямо отвечаете за убытки заказчиков, которые
H>являются результатом действия или бездействия вашего ПО, то это достойно
H>удивления. И даже, честно сказать, с трудом в это верится без конкретных
H>фактов-то. Максимум на что хватает моей фантазии — это то, что вы может
H>быть подписываетесь на бесплатную техподдержку и штрафы за невыполнение SLA.

Ну есть разные способы держать рядом с собой клиентов. Ради этого нужно удовлетворять
их потребности в непрерывной работе нашего софта. Много работников компаний-клиентов начинают
и заканчивают свой день запуском/выключением/входом/выходом нашего софта, так что простой —
считайте что человек не выполнял свои прямые обязанности.
Прямо, конечно деньгами, не отвечаем, но косвенно конечно — недовольство клиента — не будет
продолжения использования софта, оплаты ежегодной техподдержки и кучи дополнительных договоров
по внедрению, доработкам и интеграции. Где-то же надо брать кучу денег на содержание
девелоперов и плюшки владельцам компании

H>Вы вообще на яве-то, извиняюсь, пишете?

Эээээ.... да не, просто так, форум местный почитываю....
Максимум — писал на бейсике в школе

H>Ну я так понял названий-то не будет?

Поняли? Ок....
...Да.. не будет

Давайте что ли отдельно попереписываемся, если интересно. Оффтопик же.

Здравствуйте, Hard_Club, Вы писали:

H_C>Недавно прочитал в одной книге, что с помощью assert нельля проверять аргументы в публичных методах, т.к. его можно оключить, а public-методы должны всегда проверять входящие параметры. Откуда взялось такое правило? Кто его установил?

http://stackoverflow.com/a/1957656

Assertions are designed to be cheap to write, you can use them almost everywhere and I'm using this rule of thumb: the more an assertion statement looks stupid, the more valuable it is and the more information it embeds. When debugging a program that does not behave the right way, you will surely check the more obvious failure possibilities based on your experience. Then you will check for problems that just cannot happen: this is exactly when assertions help a lot and save time.

согласен с выделенным, сдается мне что именно из этих соображений Блох и компания добавила их в язык.

Здравствуйте, insighter, Вы писали:

I>
I>http://stackoverflow.com/a/1957656
I>

Вот странные там по ссылке примеры приводят.
"...assertion could be used to check that the harddrive suddenly disapears..."
С чего бы вдруг? Внезапное исчезновение harddrive вполне себе часто встречающаяся ситуация без какой-либо мистики.
Много софта корректно это обрабатывает, просто переставая с ним работать.

И вообще — любой ресурс (диск, файл, канал связи, база данных и т.п.) может "внезапно" исчезнуть.
Но приложение, как правило, выполняет много разных функций, связанных не только с исчезнувшим ресурсом.
И если такое произошло, то вот пусть и "отключатся" те 20%-40%-60% функций, которым этот ресурс нужен, но
остальные 80%-60%-40% функционала пусть продолжают работать.

Мелкие утилиты, которые 100% завязаны на какой-то ресурс, так же не должны просто падать из-за этого,
а должны как минимум вывести сообщение о недоступности ресурса, а лучше — продолжить выполнение
в ограниченном режиме, ожидая возможного восстановления доступа к ресурсу.

P.S.: Я, например, начал дискутировать в этой теме только с одной целью — вдруг кто-то покажет реальный пример, где все это нужно. И пока что-то никак.

Здравствуйте, _newcomer_, Вы писали:

__>Вот странные там по ссылке примеры приводят.
__>"...assertion could be used to check that the harddrive suddenly disapears..."
Да в интернете много чего странного можно прочитать. Например про то, что, дескать, каждый параметр надо во всех возможных вариантах проверять в каждом методе. 2 вложенных метода — значит две одинаковые проверки. 10 вложенных методов — 10 вложенных проверок. Крутяк

__>P.S.: Я, например, начал дискутировать в этой теме только с одной целью — вдруг кто-то покажет реальный пример, где все это нужно. И пока что-то никак.
Вам было приведено достаточно примеров. То, что вы не хотите их принимать, не означает, что они таковыми не являются.

	От:	Hard_Club
	Дата:	09.01.14 10:04
	Оценка:

	От:	Blazkowicz
	Дата:	09.01.14 10:13
	Оценка:

	От:	StanislavK
	Дата:	09.01.14 10:14
	Оценка:	+1

	От:	Hard_Club
	Дата:	09.01.14 10:22
	Оценка:

	От:	devcoach
	Дата:	09.01.14 10:27
	Оценка: