Это те самые, которые есть только в джаве, и задизайненые так, что половина "новых" (ver. 8+) фич с ними не работает? Я давно не слежу за языком, может что-то улучшилось?
Надеюсь, вы всегда читаете доки ко всем функциям, которые используете. При обновлении версии зависимостей перечитываете доки, всех функций из этих зависимостей. Ну и верите, что доки всегда соответствуют реальности.
Но я ленивый, люблю когда за меня компилятор работает.
Ловить что-то на верхнем уровне - это понятно. Проблема не в этом
так как ловить исключения на уровне бизнес-логики нужно все равно
Как узнать, какая именно функция должна быть обёрнута? Оборачивать каждую? Ну ок, допустим мы знаем, что библиотечная функция (к которой у нас нет доступа) может кинуть какое-то множество исключений, и хотим в этом случае подставить дефолтное значение. Внутри этой функции есть вызовы других функций, которые тоже могут кинуть исключение. И вот проблема - если ловить всё, то можем отловить что-то критичное для приложения, потому что мы не знаем полный список того, что могут выкинуть функции. И на верхнем уровне вместо реагирования на критическую ситуацию мы получим нерабочее приложение. Перечислить только известные исключения? Но тогда мы можем пропустить что-то незначительное, и вместо дефолтного значения у нас всё упадёт до верхнего уровня.
Result + panic (если ещё и писать код нормально) решают проблему разделения чего-то реально критичного, на что мы не можем адекватно отреагирвоать, и пользовательские ошибки, которые можем обработать где хотим точечно и типобезопасно - компилятор сам подскажет что в функции, условно, появилась вероятность вернуть ошибку, или список допустимых ошибок изменился. Добиться такого исключениями намного сложнее, и я нигде не видел нормальной реализации этого.
На верхнем уровне - вообще всегда нужно делать try-catch
Ну ок, вот мы ловим на верхнем уровне что-то. Теперь приложение не падает, а просто работает неправильно. А всё из-за какой-то одной функции в глубине приложения, которая вдруг стала кидать исключения. Сигнатура вроде не менялась, но теперь её поведение напрямую влияет чуть ли не на всё приложение, всё потому что забыли её обернуть в try-catch. Это ли не выстрел в ногу?
В Java вы можете описать все возможные Checked exceptions. Но это оказалось совершенно бесполезным.
Потому что было очень неудобным. И рядом с checked были и unchecked исключения, которые вроде про одно, но по факту разные концепции
достаточно сделать try catch
Как узнать, когда это делать? если
документации к функции как раз и описывается.
то сегодня функция не кидает исключения, а в следующей версии кидает, но доку не поправили. Вот и всё, ошибка как бы говорит вам "до встречи в рантайме".
Я воспринял эту книгу скорее не как историю (хотя тут есть хоть какой-то нарратив), а скорее как набор интересных (и не очень) идей, которые придумал автор. Интересно было читать примечания, откуда эти идеи были рождены. Но самих идей на 1 книгу очень много, поэтому воспринимается всё как черновик некого цикла романов, а не повесть про контакт.
А вот вторая книга из цикла сильно хуже - новых идей мало, сюжета ещё меньше. Основной концепт бог - это вирус интересный, но нормально не раскрыт.
что реально мешает айтишнику из региона устроится в на норм.зарплату?
Не все компании предоставляют удалёнку с тем же уровнем ЗП, что и офисные должности. Кто-то хочет видеть тебя 1-2 раза в неделю в офисе. Кто-то явно не пишет, но есть внутреннее распоряжение, что "не нанимаем замкадовцев".
Ну и банально, в Москве всё-таки проще постоить карьеру, потому что ты можешь поработать 1-2-3 года в офисе в "дорогой" и известной компании, которая не хочет удалёнщиков, получить строчку в резюме и уже искать что-то с удалёнкой. Если ты из региона, то у тебя просто не будет возможности получить такой опыт, потому что офисов топовых компаний там нет, и максимум ты можешь найти что-то на уровне "пилю сайт для магаза запчастей". И вот у HR 2 кандидата - у одного 3 года в условном говняндексе, а у другого 5 лет в ноунейм-фирме из провинции. Кого возьмут охотнее?
Ну это очевидно. Только спор не об этом. А о том, что обязательно надо начинать с железа, что это фундамент и база, это вечное, и без этого никуда, аж кодить нельзя. А ваши вебы - это просто временная игрушка, знания ситуационные. Ну в самом деле, что там можно накодить?
Но на деле это просто заблуждение, причём в основном сишников. Они почему-то обычно считают, что надо прям обязательно изучать всё начиная с ассемблера. А как спросишь почему - ничего дельного не говорят.
А секрет прост - можно начинать с чего угодно, потому что язык - это инструмент а не цель.
Тут в пример приводят то квадратичный reduce вместо линейного, теперь битовые флаги. Но где тут польза от знания ассемблера? Это просто алгоритмы, которые не появляются автоматически после изучения асма. Зачем так напрягаться, чтобы хоть во всё пытаться присунуть это сакральное владение ассемблером, непонятно.
На то это и пример. В реальности всё это выглядит несколько сложнее и очень неочевидно - сложные взаимосвязи данных, что-то в замыканиях, что-то в цепочках методов. И хрен пойми с первого взгляда, где ошибка (не логическая, а именно ошибка с памятью). Но в расте ты об этом узнаешь от компилятора сразу, а не по segfault.
А статические анализаторы надо прикручивать сверху. Вот сколько процентов проектов на C их используют? А в расте могу сказать, что в 100% проектов есть встроенная проверка от race-condition или null-deref, например.
Да, можно обойти эти проверки, но надо стараться сломать программу.
И даже в пределах одной функции в зависимости от контекста часть из них может быть не выполнена или выполнена в неправильном порядке.
Borrow-checker чудес не делает, по веткам и функциям не ходит, он достаточно прост. Вообще, если бы вы время, которое тратите на спор и измышлений "как там всё работает" по вашему мнению, реально почитали бы 1 статью по расту, вам стало гораздо понятнее о чём я говорю.
iPad/iPhone не дружит с ним. Я добавил синхронизацию этих девайсов через iCloud, но iCloud плохо дружит с гитом, бд гита портится постоянно
Это те самые, которые есть только в джаве, и задизайненые так, что половина "новых" (ver. 8+) фич с ними не работает? Я давно не слежу за языком, может что-то улучшилось?
Надеюсь, вы всегда читаете доки ко всем функциям, которые используете. При обновлении версии зависимостей перечитываете доки, всех функций из этих зависимостей. Ну и верите, что доки всегда соответствуют реальности.
Но я ленивый, люблю когда за меня компилятор работает.
catch с врапом забудешь сделать, компилятор промолчит.
Даже в таком варианте есть пара моментов:
Тут понятно, что ошибки вообще есть. Исключения об этом не скажут. Кроме checked в java, но их дизайн настолько плохой, что ими не пользуются
Тут надо явно (в расте) обработать их или прокинуть. Случайно нельзя забыть никак
На тебя заведут статью за вымогательство, а получателям письма будет пофиг. Ну выплатят 60к штрафа, делов-то.
Ловить что-то на верхнем уровне - это понятно. Проблема не в этом
Как узнать, какая именно функция должна быть обёрнута? Оборачивать каждую? Ну ок, допустим мы знаем, что библиотечная функция (к которой у нас нет доступа) может кинуть какое-то множество исключений, и хотим в этом случае подставить дефолтное значение. Внутри этой функции есть вызовы других функций, которые тоже могут кинуть исключение. И вот проблема - если ловить всё, то можем отловить что-то критичное для приложения, потому что мы не знаем полный список того, что могут выкинуть функции. И на верхнем уровне вместо реагирования на критическую ситуацию мы получим нерабочее приложение. Перечислить только известные исключения? Но тогда мы можем пропустить что-то незначительное, и вместо дефолтного значения у нас всё упадёт до верхнего уровня.
Result + panic (если ещё и писать код нормально) решают проблему разделения чего-то реально критичного, на что мы не можем адекватно отреагирвоать, и пользовательские ошибки, которые можем обработать где хотим точечно и типобезопасно - компилятор сам подскажет что в функции, условно, появилась вероятность вернуть ошибку, или список допустимых ошибок изменился. Добиться такого исключениями намного сложнее, и я нигде не видел нормальной реализации этого.
Ну только их не используют почти никогда.
Ну ок, вот мы ловим на верхнем уровне что-то. Теперь приложение не падает, а просто работает неправильно. А всё из-за какой-то одной функции в глубине приложения, которая вдруг стала кидать исключения. Сигнатура вроде не менялась, но теперь её поведение напрямую влияет чуть ли не на всё приложение, всё потому что забыли её обернуть в try-catch. Это ли не выстрел в ногу?
Лучше наоборот - боты будут спрашивать, а кожмешки отвечать. Так и дообучим ИИ до
скайнетанормального состояния.Функция раньше не кидала исключений, а вдруг стала. Как такое отследить на этапе компиляции?
Потому что было очень неудобным. И рядом с checked были и unchecked исключения, которые вроде про одно, но по факту разные концепции
Как узнать, когда это делать? если
то сегодня функция не кидает исключения, а в следующей версии кидает, но доку не поправили. Вот и всё, ошибка как бы говорит вам "до встречи в рантайме".
Я воспринял эту книгу скорее не как историю (хотя тут есть хоть какой-то нарратив), а скорее как набор интересных (и не очень) идей, которые придумал автор. Интересно было читать примечания, откуда эти идеи были рождены. Но самих идей на 1 книгу очень много, поэтому воспринимается всё как черновик некого цикла романов, а не повесть про контакт.
А вот вторая книга из цикла сильно хуже - новых идей мало, сюжета ещё меньше. Основной концепт бог - это вирус интересный, но нормально не раскрыт.
И запретить / предупреждать про
unwrapна уровне проекта бесплатно без смс:То есть вести заметки, а не хранить всё в голове - "Это как ходить по улице исключительно вприсядку"?
Не все компании предоставляют удалёнку с тем же уровнем ЗП, что и офисные должности. Кто-то хочет видеть тебя 1-2 раза в неделю в офисе. Кто-то явно не пишет, но есть внутреннее распоряжение, что "не нанимаем замкадовцев".
Ну и банально, в Москве всё-таки проще постоить карьеру, потому что ты можешь поработать 1-2-3 года в офисе в "дорогой" и известной компании, которая не хочет удалёнщиков, получить строчку в резюме и уже искать что-то с удалёнкой. Если ты из региона, то у тебя просто не будет возможности получить такой опыт, потому что офисов топовых компаний там нет, и максимум ты можешь найти что-то на уровне "пилю сайт для магаза запчастей". И вот у HR 2 кандидата - у одного 3 года в условном говняндексе, а у другого 5 лет в ноунейм-фирме из провинции. Кого возьмут охотнее?
Ну это очевидно. Только спор не об этом. А о том, что обязательно надо начинать с железа, что это фундамент и база, это вечное, и без этого никуда, аж кодить нельзя. А ваши вебы - это просто временная игрушка, знания ситуационные. Ну в самом деле, что там можно накодить?
Но на деле это просто заблуждение, причём в основном сишников. Они почему-то обычно считают, что надо прям обязательно изучать всё начиная с ассемблера. А как спросишь почему - ничего дельного не говорят.
А секрет прост - можно начинать с чего угодно, потому что язык - это инструмент а не цель.
Тут в пример приводят то квадратичный reduce вместо линейного, теперь битовые флаги. Но где тут польза от знания ассемблера? Это просто алгоритмы, которые не появляются автоматически после изучения асма. Зачем так напрягаться, чтобы хоть во всё пытаться присунуть это сакральное владение ассемблером, непонятно.
native, web - javascript или webasm, ios через multiplatform
Идите до конца. Художественная литература - просто буквы на мёртвом дереве. Фильмы - лишь пиксели на экране.
На то это и пример. В реальности всё это выглядит несколько сложнее и очень неочевидно - сложные взаимосвязи данных, что-то в замыканиях, что-то в цепочках методов. И хрен пойми с первого взгляда, где ошибка (не логическая, а именно ошибка с памятью). Но в расте ты об этом узнаешь от компилятора сразу, а не по segfault.
А статические анализаторы надо прикручивать сверху. Вот сколько процентов проектов на C их используют? А в расте могу сказать, что в 100% проектов есть встроенная проверка от race-condition или null-deref, например.
Да, можно обойти эти проверки, но надо стараться сломать программу.
Borrow-checker чудес не делает, по веткам и функциям не ходит, он достаточно прост. Вообще, если бы вы время, которое тратите на спор и измышлений "как там всё работает" по вашему мнению, реально почитали бы 1 статью по расту, вам стало гораздо понятнее о чём я говорю.