Хм, а зачем перебирать в catch все типы исключений? Обрабатывай те, которые хочешь рассмотреть отдельно, а остальное закроется catch(). Если уж в языке нормально сделаны исключения, то и возможность поймать "все" тоже поддерживается. Ну или ловить все по базовому классу, это тоже стандартная практика (и правильная).
Ну и до main редко долетает, обычно все ловится гораздо раньше, на уровне фреймворков, но это если не хочется их ловить раньше.
На этапе компиляции отсутствие или некорректный try-catch, кстати, вполне отслеживаются хорошими линтерами (ну, если в языке есть средства для нормального статанализа, типа Java или C#). Так что тут тоже нет проблем с контролем.
При этом логика работы с exception (именно как исключениями) гораздо удобнее и не приходится ее копировать другими средствами, как делают в Go.
На верхнем уровне - вообще всегда нужно делать try-catch (для unchecked exception), так как всегда могут быть системные исключения. А для checked - компилятор подскажет. Но checked - это просто более удобный способ для "кодов возврата", но в сравнении с unchecked оказался неудобным.
Ну, исключения должны перехватываться там, где можно принять решение о retry или cancel. Это не всегда низкий уровень, часто это уровень бизнес-логики или вообще обработчика команд.
Хм, просто убедиться, что на верхнем уровне есть try catch. Если использовать стандартные фреймворки - то он точно есть. А в Java можно сделать checked exception, тогда компилятор подсветит все места, где исключение не обработано.
В Java вы можете описать все возможные Checked exceptions. Но это оказалось совершенно бесполезным. Но при вызове функции вообще не нужно знать, какие именно исключения она может выкинуть, достаточно сделать try catch и вернуть сообщение про текущий контекст. Исключения - это не про базовый поток управления, это про исключительные ситуации и нужно только знать, что они бывают. Крайне редко нужно знать, какие именно произошли ситуации - и это в документации к функции как раз и описывается.
Но в Java как раз есть исключения - и они скорее помогают рефакторингу. Да, в языках с динамической типизации все сложнее с рефакторингом (и да, они гораздо менее пригодны для создания надежных или больших систем), но мы же про Go или Rust, где таких проблем быть не должо.
Ага. В конечном счете ошибки делятся на три группы: "можно попробовать еще раз", "можно попросить пользователя попробовать еще раз с другими данными", "ничего нельзя сделать". И большая часть возни с ошибками - это подсказки пользователю для второй группы (или программисту для третьей).
Есть дизайн, где исключения как раз дают гарантии, что их отловили (checked exception в Java), правда на поверку оказалось, что это неудобно. В "нормальных" языках как раз есть гарантии в том, что исключения отлавливаемы стандартными конструкциями (за это отвечает банальный try catch). Более того, ошибки в стиле Go с гораздо большей вероятностью приведут к их пропуску, чем исключения (просто из-за больших шансах при очередной явной обработке пропустить ошибку, а не прокинуть выше).
Наличие исключений в серверной логике как раз увеличивает надежность кода - ошибка точно не распространится дальше конкретной команды и точно будет отловлена минимум на уровне фреймворка (обычно несколько раньше).
Хм, а зачем нужно составлять список всех исключений, как с решением этой же задачи поможет переход на C-style и причем тут плохой дизайн Python (в той же Java нет проблем с перехватом всех возможных исключений)
Хм, а можешь пояснить, как именно исключения влияли на производительность? По идее же исключения отъедают ресурсы только тогда, когда они случаются, а этого, по идее, не должно происходить часто.
Ну, про "классную" я не был бы столь уверен. Да, есть несколько правильных мыслей, но и всяких некорректных заключений очень много. Я бы не советовал эту статью неопытному разработчику (а опытному она тем более не нужна). Впрочем, нормальных ресурсов по МСА довольно мало (
Не совсем понятно, откуда взялись именно такие наборы характеристик? На основании какой психологической модели они выделены? Вроде бы на Big5 совсем не похоже, а других вменяемых моделей с доказанной корреляцией с поведением вроде бы и нет.
Если про архитектуру, то стоит читать Фаулера. Про выборы неплохо написано в 'Software Architecture: The Hard Parts' Нила Форда и других. При этом надо помнить, что в любой книжке процентов 30% - 70% или устарело или просто фигня и смысл книг - в узнавании нового и возможности поспорить с кем-то опытным, но никогда - не готовые советы.
Перед любыми книжками по архитектуре неплохо освоить базу, ту же теорию систем (Акофф, Левенчук, Смирнов - подбирай по вкусу), распределенные системы от Клеппмана и прочие базовые вещи типа сети. Но, освоение базовых умений в проектировании требует минимум лет 8-10 опыта в разных компаниях, довольно много разных книжек, много разных общих знаний - и только потом уже от проектирования будет польза.
Ну и в качестве развлечения можно смотреть доклады на основных конференциях. Верить им нельзя (даже моим), но как увеличение широты и начитанности - полезны.
Угу. Не позволяет определить навыки или компетенции, связанные с реальной выполняемой работой. Собеседование по SysDesign (в большинстве видов, исключения бывают, но крайне редкие) показывает только умение кандидата читать сомнительные книжки и не слишком задумываться - и больше ничего. Впрочем, может в некоторых компаниях это и является важным критерием отбора...
Хм, а зачем перебирать в catch все типы исключений? Обрабатывай те, которые хочешь рассмотреть отдельно, а остальное закроется catch(). Если уж в языке нормально сделаны исключения, то и возможность поймать "все" тоже поддерживается. Ну или ловить все по базовому классу, это тоже стандартная практика (и правильная).
Ну и до main редко долетает, обычно все ловится гораздо раньше, на уровне фреймворков, но это если не хочется их ловить раньше.
На этапе компиляции отсутствие или некорректный try-catch, кстати, вполне отслеживаются хорошими линтерами (ну, если в языке есть средства для нормального статанализа, типа Java или C#). Так что тут тоже нет проблем с контролем.
При этом логика работы с exception (именно как исключениями) гораздо удобнее и не приходится ее копировать другими средствами, как делают в Go.
На верхнем уровне - вообще всегда нужно делать try-catch (для unchecked exception), так как всегда могут быть системные исключения.
А для checked - компилятор подскажет. Но checked - это просто более удобный способ для "кодов возврата", но в сравнении с unchecked оказался неудобным.
Так exceptiontrap тоже сами по себе стек не задействуют.
А ifы иногда сильно мешают оптимизациям внутри ядра процессора
А зачем? Какой смысл в этой аннотации, что ты будешь с ней делать?
Хм, и как ты пробросом исключения прострелишь ногу? Игнорированием ошибки - да, легко и это чаще встречается для Result или checked exception.
Угу, но этих строчек, по идее, должно быть на порядки меньше, нежели явных if, так что оно не должно сказываться на производительности.
Ну, исключения должны перехватываться там, где можно принять решение о retry или cancel. Это не всегда низкий уровень, часто это уровень бизнес-логики или вообще обработчика команд.
Хм, просто убедиться, что на верхнем уровне есть try catch. Если использовать стандартные фреймворки - то он точно есть.
А в Java можно сделать checked exception, тогда компилятор подсветит все места, где исключение не обработано.
В Java вы можете описать все возможные Checked exceptions. Но это оказалось совершенно бесполезным.
Но при вызове функции вообще не нужно знать, какие именно исключения она может выкинуть, достаточно сделать try catch и вернуть сообщение про текущий контекст.
Исключения - это не про базовый поток управления, это про исключительные ситуации и нужно только знать, что они бывают. Крайне редко нужно знать, какие именно произошли ситуации - и это в документации к функции как раз и описывается.
Но в Java как раз есть исключения - и они скорее помогают рефакторингу.
Да, в языках с динамической типизации все сложнее с рефакторингом (и да, они гораздо менее пригодны для создания надежных или больших систем), но мы же про Go или Rust, где таких проблем быть не должо.
Ага. В конечном счете ошибки делятся на три группы:
"можно попробовать еще раз", "можно попросить пользователя попробовать еще раз с другими данными", "ничего нельзя сделать". И большая часть возни с ошибками - это подсказки пользователю для второй группы (или программисту для третьей).
Ну, checked exceptions - очень похожи на обязательные коды возврата )
Есть дизайн, где исключения как раз дают гарантии, что их отловили (checked exception в Java), правда на поверку оказалось, что это неудобно.
В "нормальных" языках как раз есть гарантии в том, что исключения отлавливаемы стандартными конструкциями (за это отвечает банальный try catch).
Более того, ошибки в стиле Go с гораздо большей вероятностью приведут к их пропуску, чем исключения (просто из-за больших шансах при очередной явной обработке пропустить ошибку, а не прокинуть выше).
Наличие исключений в серверной логике как раз увеличивает надежность кода - ошибка точно не распространится дальше конкретной команды и точно будет отловлена минимум на уровне фреймворка (обычно несколько раньше).
Хм, а зачем нужно составлять список всех исключений, как с решением этой же задачи поможет переход на C-style и причем тут плохой дизайн Python (в той же Java нет проблем с перехватом всех возможных исключений)
Хм, а можешь пояснить, как именно исключения влияли на производительность?
По идее же исключения отъедают ресурсы только тогда, когда они случаются, а этого, по идее, не должно происходить часто.
Ну, про "классную" я не был бы столь уверен. Да, есть несколько правильных мыслей, но и всяких некорректных заключений очень много. Я бы не советовал эту статью неопытному разработчику (а опытному она тем более не нужна).
Впрочем, нормальных ресурсов по МСА довольно мало (
Не совсем понятно, откуда взялись именно такие наборы характеристик? На основании какой психологической модели они выделены? Вроде бы на Big5 совсем не похоже, а других вменяемых моделей с доказанной корреляцией с поведением вроде бы и нет.
Если про архитектуру, то стоит читать Фаулера. Про выборы неплохо написано в 'Software Architecture: The Hard Parts' Нила Форда и других.
При этом надо помнить, что в любой книжке процентов 30% - 70% или устарело или просто фигня и смысл книг - в узнавании нового и возможности поспорить с кем-то опытным, но никогда - не готовые советы.
Перед любыми книжками по архитектуре неплохо освоить базу, ту же теорию систем (Акофф, Левенчук, Смирнов - подбирай по вкусу), распределенные системы от Клеппмана и прочие базовые вещи типа сети. Но, освоение базовых умений в проектировании требует минимум лет 8-10 опыта в разных компаниях, довольно много разных книжек, много разных общих знаний - и только потом уже от проектирования будет польза.
Ну и в качестве развлечения можно смотреть доклады на основных конференциях. Верить им нельзя (даже моим), но как увеличение широты и начитанности - полезны.
Посоветовать для чего?
Что хочется изучить/освоить/понять?
Угу. Не позволяет определить навыки или компетенции, связанные с реальной выполняемой работой.
Собеседование по SysDesign (в большинстве видов, исключения бывают, но крайне редкие) показывает только умение кандидата читать сомнительные книжки и не слишком задумываться - и больше ничего. Впрочем, может в некоторых компаниях это и является важным критерием отбора...