Не притворяйся как будто не понял о чем пишу. Весь контент по программированию на английском зачем вообще русские слова юзать тогда.@fomenkogregory, иф ол ов контент ин Инглиш, вай ду ю райт ин Рашн он дэ текникал ресурс? nadeus' ponyatno stalo, pochemu po-angliiski ludi pishut latinicey, a po-russki - kirilicey?
но 20 миллионов нищих граждан России я думаю скажут обратное.Ярослав Александров, конечно, зависть то к счастью не приводит... В совке почти все были обречены быть нищими, кроме горстки людей, которые обзавелись нужными знакомствами и завидовать некому было. А сейчас есть возможности, вот только тем, кто по каким-то причинам не в состоянии поднять свою 5 точку, остается только завидовать, ибо на большее не способны... Какое уж тут счастье?
мысль интересная, но "если да кабы", в данном случае точно известно, что нет там никаких переопределённых операторов, это обычная строка.Я бы не был так уверен работая с completeness type system. Ну и даже если сегодня там строка, от которой нельзя наследоваться, никто не гарантирует, что завтра эту строку не завернут в декоратор, и у него не будет перегрузки операторов. И тайпчекер ничего не скажет, что проверка на null вдруг стала некорректной. И даже если здесь всегда будет строка, в других местах может быть не строка, и у Вас будет 100500 разных вариантов сделать одно и то же, либо будут ошибки.
Зачем выдумывать какую-то надёжность и проблему, которой нет и быть не может?Если бы проблемы не было, то с развитием языка не появлялись бы способы для ее решения. Проблема огромна, большинство ПО пестрит багами, и большинство из них существуют из-за таких вот "я не вижу проблем, я не хочу развиваться, я застрял в 90х и мне норм, пишу как умею".
Если проверка на null кинет эксепшен, то это нужно исправить тому, кто пишет код, а не "надёжной" проверкой скрывать проблему.То есть по Вашему лучше переложить ответственность, заодно наложив искусственные неявные ограничения, вместо того чтоб решить проблему на корню? Использование более надежного подхода как раз таки не скрывает проблему, а решает ее.
И причём здесь вообще библиотека и функциональный подход?А причем тут функциональный подход? Или увидели монады и все, "а-а-а, ФП, сложна, лучше пойду дальше быдлокодить"? Так вот, монады это не про ФП, монады это про гарантии, что с данными будут работать корректно. И да, ошибки - это тоже данные, поэтому их нужно возвращать как результат, а не бросать вместе с исключительными ситуациями, и монада Either (или аналоги) идеально для этого подходит, так как гарантирует, что вызывающая сторона не получит свои данные пока не обработает ошибку. Механизм throw-try-catch ничего не гарантирует, а на практике он приводит к скрытым багам из-за нарушенного потока данных.
чем операция is более надёжна? Чем проверка
!(value is null)
надёжнее такой проверки?
value != null
про исключение вообще забавно. Особенно про нечитаемый файл и возврат с помощью return. И что нужно по вашему вернуть через return, если файл не читается? Слово Error :)? Нужно бросать исключение, а если быть точным, то оно будет брошено методом класса фреймворка, если файл не удастся открыть. Какие могут быть баги, если try catch на уровне метода нажатия на кнопку и пользователь знает об ошибке? В данной ситуации try catch нужно использовать, а не крашить приложение.