Не притворяйся как будто не понял о чем пишу. Весь контент по программированию на английском зачем вообще русские слова юзать тогда.@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 нужно использовать, а не крашить приложение.
Не нужно от них избавляться. Если это нажатие на кнопку, там ему самое место, просто нужно или залогировать информацию об ошибке, или вывести информацию на экран (или всё вместе). Если бы он в классе с алгоритмом подавлял ошибки, то да, это было бы не то что неподдерживающийся хаос, это просто был бы нерабочий код, который нельзя так писать. Проще говоря, если не будет трай кэтча в методе нажатия на кнопку, то приложение будет просто крашиться. Мы же можем приложение не крашить, а просто завершить выполнение работы не получив результат. В таком случае, имея логи, можно разобраться в проблеме. Бывают ошибки, не связанные с алгоритмом, например, антивирус заблокировал файл, не удалось его открыть и прочитать. У меня такое было.Если произошло исключение (исключительная ситуация) - программа должна была падать, ибо это косяк программиста и его надо ловить как можно раньше. Если файл не читается - это не исключение, а ошибка, ее не надо кидать через throw, ее нужно возвращать через return и обрабатывать, ибо это штатная ситуация, ожидаемый результат вызова. Вездесущие try-catch - рассадник багов.
v != null
type Union = 'a' | 'b' | 'c';
type Obj<U extends string> = {
[K in U]: any;
};вообще в 20 раз вышло
first for: 78.940ms
----------------------
second for: 1536.180ms
где-то в 1.5 раза...
first for: 108.457ms
----------------------
second for: 1.829s