этот контракт всем доступен, значит клиент может выполнить эти условия, а значит нарушение контракта сигнализирует о неверном коде. т.о ничего ловить не надо, надо закрашиться
надо ли делать так всегда? конечно же нет, иначе будет еще один замечательный чистый язык, на котором никто ничего не пишет, а компромиссы в простых случаях даже не приемлемы, а желанны
а вообще за всю мою практику из наследников SystemException мне приходилось ловить и проглатывать только TaskCanceledException, все что было связано с арифметикой — это всегда была моя ошибка
возврат DBZ — часть естественного контракта функции. Функции деления, например.
нет
в программе кнопок больше одной, одна может не работать. Главное — побочных эффектов не настругать.
и что? не работает — перепиши
Функция может работать в рамках контракта, который мы где-то нарушили. Самое банальное — плохо проверили пользовательский ввод. Нехорошо, но не смертельно — введут ещё раз.
контракт нарушен -> написано неверено -> смысла работать дальше нет
если бы получили DBZ из функции, значит функция написана неверено, какой смысл что-то изолировать, если у вас программа написана неверно? хоть какой-то смысл это имеет на границе плагина или чего-то такого что можно безболезненно прибить и оно при этом нам не подконтрольно
если у вас ожидается что инты будут переполняться, то, очевидно, использовать механизм исключений для этого глубоко неправильно. Впрочем как и ловля любого SystemException без rethrow
тогда, очевидно, должен быть способ задать поведение по умолчанию. А оно может быть различным для каждого случая, и тогда начинаем использовать?.. и ??, либо различным для каждого типа, тогда нам нужен или Null Object или типизированный null(еще вопрос где описать поведение такого null). Все это очень сложно, гораздо проще не иметь дела с null вообще, и тогда, возможно, мы увидим какой-то сахар для этого в языке
>Что? Нет! Ну как, конечно если язык падает при доступе к такой переменной и заставляет ее всячески обворачивать то да, ошибка. А так — нет. И никаких лишних движений.
Почему if(something != null) вдруг „антипаттерн“? Единственное назначение которого — выбросить исключение поближе к месту предательства“ — никто не выбрасывает NullReferenceException и никто не отменял валидацию параметров метода (InvalidArgumentException) или ошибочных сценариев (InvalidOperationException).
потому что в свете последних за 20 лет веяний в ООП эта задача должна быть переложена на контракты
В Optional ещё можно лямбду выполнить если там пусто и ещё много чего можно
все тоже самое, там должно быть просто выражение
Кроме того Optional в сигнатуре медота означает, что метод может вернуть пустое значение. Синтаксис чище выходит. Не надо гадать, может там быть пустое значение, или нет.
да, это плюс
Но с таким подходом наверное лучше особый синтаксис делать для мест в которых null не может вернуться — их меньше.
в дотнете ровно все наоборот, обычно это нежданчик когда тебя null отдали, но в тех местах, где это есть, обьёмы кода впечатляют
вот только там он протеворечит сам себе, потому что то, что он показал это ActiveRecord и repository, и совершенно верно ему об этом рассказали. При этом рассказывает какие-то сказки про active record, очевидно не читав даже определения
забавно, как раз 2 года назад на ASP.NET MVC написали прилагу с рейтингом эло для кикера. Я аж сначала подумал, что кто-то из наших запостил, настолько похоже ))
а инпут к формуле?
>А во сколько раз дольше ваша проверка будет считаться (да и писаться, с тестами), чем само вычисление?
один раз — при комипяции. вы вообще слышали про контракты?
ну если делаем лабораторку в универе, то можно и не обкладывать )) а какие еще есть варианты? input всегда нужно валидировать
я попробую раскрыть свою мысль: если мы говорим, например, про деление то контракт у деления должен выгялдить вот так:
Contract.Require(divisor != 0);
если мы говорим про overflow то у функции сложения контракт будет вглядеть вот так:
Contract.Require(int.MaxValue — arg1 > arg2 && int.MaxValue — arg2 > arg1);
этот контракт всем доступен, значит клиент может выполнить эти условия, а значит нарушение контракта сигнализирует о неверном коде. т.о ничего ловить не надо, надо закрашиться
надо ли делать так всегда? конечно же нет, иначе будет еще один замечательный чистый язык, на котором никто ничего не пишет, а компромиссы в простых случаях даже не приемлемы, а желанны
а вообще за всю мою практику из наследников SystemException мне приходилось ловить и проглатывать только TaskCanceledException, все что было связано с арифметикой — это всегда была моя ошибка
нет
и что? не работает — перепиши
контракт нарушен -> написано неверено -> смысла работать дальше нет
Framework Design Guidelines
Единственное, что можно сделать: поймать, написать логи/дампы/перезапуск и упасть. NRE это однозначная ошибка в коде, работать дальше смысла не имеет
code contracts
потому что в свете последних за 20 лет веяний в ООП эта задача должна быть переложена на контракты
это пять ))
все тоже самое, там должно быть просто выражение
да, это плюс
в дотнете ровно все наоборот, обычно это нежданчик когда тебя null отдали, но в тех местах, где это есть, обьёмы кода впечатляют
все уже давно есть ))
C#?
int:
string: