В этот раз прорабатывались следующие большие темы:
В этот раз без внимания не остались темы:
Привет, я Антон Полухин из Техплатформы Екома и Райдтеха Яндекса. Моя команда разрабатывает userver — современный опенсорсный асинхронный фреймворк с богатым набором абстракций для быстрого и комфортного создания микросервисов, сервисов и утилит на C++.
Когда мы пишем какой‑то код для userver и для таких сложных проектов, как BoostЧитать полностью »
Качественная обработка ошибок — это ключ к созданию надёжных программ; но программистов она часто пугает, ведь всегда найдётся ещё один пограничный случай.
В традиционных объектно-ориентированных языках программирования используются специальные классы исключений, которые можно выбрасывать, чтобы прекратить обычный поток управления и немедленно сообщить об ошибке.
Давайте рассмотрим пример, в котором применено защищённое от ошибок целочисленное деление:
int safeDiv(int a, int b) {
if (b == 0)
throw Div0(); // Исключения передаются особым образом
return a / b; // Теперь-то всё абсолютно безопасно, ведь так?
}
Новые языки программирования склонны применять сообщения об ошибках в функциональном стиле и кодировать ошибки в возвращаемый тип. Например, Go кодирует ошибку в возвращаемый тип при помощи кортежа (res, err), а Rust возвращает Result<T, E> — тип-сумму результата и ошибки.
Читать полностью »
С момента моей прошлой публикации состоялось уже две встречи международного комитета по стандартизации C++.
Комитет занимался полировкой C++23:
static operator[];static constexpr в constexpr-функциях;std::print с другими консольными выводами;std::expected;static_assert(false) и прочее.И прорабатывал новые фичи C++26:
std::get и std::tuple_size для агрегатов;#embed;std::stacktrace из исключений;Java — это универсальный язык программирования, имеющий много альтернативных решений для ваших определённых задач. Тем не менее, существуют хорошие подходы, которым следует следовать, и также существуют некоторые неудачные подходы, которые мы до сих пор в большинстве своём используем.
Один из наиболее распространённых неудачных подходов — это использование исключений для контроля потока выполнения. Этого следует избегать по двум причинам:
Существуют различные способы обработки ошибок в языках программирования:
Исключения используются очень широко, с другой стороны о них часто говорят, что они медленные. Но и противники функционального подхода часто апеллируют к производительности.
Последнее время я работаю со Scala, где в равной мере я могу использовать как исключения так и различные типы данных для обработки ошибок, поэтому интересно какой из подходов будет удобнее и быстрее.
Сразу отбросим использование кодов и флагов, так как этот подход не принят в JVM языках и по моему мнению слишком подвержен ошибкам (прошу прощения за каламбур). Поэтому будем сравнивать исключения и разные виды АТД. Кроме того АТД можно рассматривать как использование кодов ошибок в функциональном стиле.
UPDATE: к сравнению добавлены исключения без стек-трейсов
![[DotNetBook] Время занимательных историй: исключительно исключительные ситуации - 1](https://www.pvsm.ru/images/2018/08/20/DotNetBook-vremya-zanimatelnyh-istorii-isklyuchitelno-isklyuchitelnye-situacii.jpeg "[DotNetBook] Время занимательных историй: исключительно исключительные ситуации - 1")
Существует ряд исключительных ситуаций, которые скажем так… Несколько более исключительны чем другие. Причем если попытаться их классифицировать, то как и было сказано в самом начале главы, есть исключения родом из самого .NET приложения, а есть исключения родом из unsafe мира. Их в свою очередь можно разделить на две подкатегории: иcключительные ситуации ядра CLR (которое по своей сути — unsafe) и любой unsafe код внешних библиотек.
Давайте поговорим про эти особые исключительные ситуации.
Вообще, это может показаться не очевидным, но существует четыре типа Thread Abort.
Данная статья — третья из четырех в цикле статей про исключения. Полный цикл:
— Архитектура системы типов
— Cобытия об исключительных ситуациях
— Виды исключительных ситуаций (эта статья)
— Сериализация и блоки обработки
![[DotNetBook] События об исключительных ситуациях и как на пустом месте получить StackOverflow и ExecutionEngineException - 1](https://www.pvsm.ru/images/2018/08/16/DotNetBook-sobytiya-ob-isklyuchitelnyh-situaciyah-i-kak-na-pustom-meste-poluchit-StackOverflow-i-ExecutionEngineException.jpeg "[DotNetBook] События об исключительных ситуациях и как на пустом месте получить StackOverflow и ExecutionEngineException - 1")
С этой статьей я продолжаю публиковать целую серию статей, результатом которой будет книга по работе .NET CLR, и .NET в целом. За ссылками — добро пожаловать по кат.
В общем случае мы не всегда знаем о тех исключениях, которые произойдут в наших программах потому что практически всегда мы используем что-то, что написано другими людьми и что находится в других подсистемах и библиотеках. Мало того что возможны самые разные ситуации в вашем собственном коде, в коде других библиотек, так еще и существует множество проблем, связанных с исполнением кода в изолированных доменах. И как раз в этом случае было бы крайне полезно уметь получать данные о работе изолированного кода. Ведь вполне реальной может быть ситуация, когда сторонний код перехватывает все без исключения ошибки, заглушив их fault блоком:
try {
// ...
} catch {
// do nothing, just to make code call more safe
}В такой ситуации может оказаться что выполнение кода уже не так безопасно как выглядит, но сообщений о том что произошли какие-то проблемы мы не имеем. Второй вариант — когда приложение глушит некоторое, пусть даже легальное, исключение. А результат — следующее исключение в случайном месте вызовет падение приложения в некотором будущем от случайной казалось бы ошибки. Тут хотелось бы иметь представление, какая была предыстория этой ошибки. Каков ход событий привел к такой ситуации. И один из способов сделать это возможным — использовать дополнительные события, которые относятся к исключительным ситуациям: AppDomain.FirstChanceException и AppDomain.UnhandledException.
Данная статья — первая из четырех в цикле статей про исключения. Полный цикл:
— Архитектура системы типов
— Cобытия об исключительных ситуациях (эта статья)
— Виды исключительных ситуаций
— Сериализация и блоки обработки
![[DotNetBook] Исключения: архитектура системы типов - 1](https://www.pvsm.ru/images/2018/08/13/DotNetBook-isklyucheniya-arhitektura-sistemy-tipov.jpeg "[DotNetBook] Исключения: архитектура системы типов - 1")
С этой статьей я продолжаю публиковать целую серию статей, результатом которой будет книга по работе .NET CLR, и .NET в целом. За ссылками — добро пожаловать по кат.
Наверное, один из самых важных вопросов, который касается темы исключений — это вопрос построения архитектуры исключений в вашем приложении. Этот вопрос интересен по многим причинам. Как по мне так основная — это видимая простота, с которой не всегда очевидно, что делать. Это свойство присуще всем базовым конструкциям, которые используются повсеместно: это и IEnumerable, и IDisposable и IObservable и прочие-прочие. С одной стороны, своей простотой они манят, вовлекают в использование себя в самых разных ситуациях. А с другой стороны, они полны омутов и бродов, из которых, не зная, как иной раз и не выбраться вовсе. И, возможно, глядя на будущий объем у вас созрел вопрос: так что же такого в исключительных ситуациях?