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 предлагает использовать их повсеместно и, как следствие, поведение системы будет непредсказуемым в куче мест.

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