По информации Bleeping Computer, ИБ-эксперты обнаружили уязвимость в работе антивирусного приложения Microsoft Defender. Любой пользователь Windows 7 и 10 может видеть список исключения для сканирования с помощью команды reg query и определенного ключа в реестре.

После установки февральских обновлений безопасности Windows 10 непривилегированному пользователю теперь нельзя посмотреть все папки в системе, которые антивирус Microsoft Defender не проверяет, а также файлы, расширения или процессы, указанные в настройках программы как исключения.

По информации Bleeping Computer, Microsoft устранила уязвимость в работе антивирусного приложения Microsoft Defender. Из-за этой проблемы любой пользователь Windows 10, включая корпоративные версии, мог видеть список исключения для сканирования. Теперь это доступно только администратору.

Данная статья расчитана для двух типов разработчиков:
— кто еще не знаком с исключениями
— кто пытается найти более разумное использование исключениям

В статье я расскажу о самых основах исключений, о том как можно обходиться без них, а так же о том, как я вижу правильным использование некоторых возможностей языка…

Эволюция языков программирования приводит иногда к кардинальным изменениям в мировоззрении разработчиков. В мире РНР такое случилось при появлении пятой ветки, которая принесла новую объектную модель, новые наборы встроенных функций и новые методы обработки ошибок…

Те, кто начинал знакомиться с PHP (тут и далее я буду подразумевать пятую версию), после другого процедурного языка программирования, так и не поняли что же такого в переходе от 4ки к 5ке и продолжают оформлять код привычными функциями, которые находятся на одном уровне по отношению друг к другу, а так же каждое действие проверяют на удачный код возврата. Но те кто знали об исключениях и классах…

Еще одна капля в наш стакан Руби (1, 2, 3, 4, 5, 6, 7, 8, 9, 10). Поговорим о self, работе с CSV и обработке исключений.

Описывая и обсуждая компьютерные программы, мы часто используем образные и человеческие метафоры. Например, мы говорим, что находимся в классе или возвращаемся из вызова метода. Иногда имеет смысл говорить во втором лице, например, object.respond_to?("x"): “Эй, объект, ты ответишь на х? И пока программа интепретируется контекст меняется снова и снова.

Некоторые объекты везде означают одно и тоже, например, числа и ключевые слова вроде def и class. Однако значение большинства элементов зависит от контекста.

Жаль, если ваше изучение концепции исключений закончится чтением соответствующего раздела официальной документации по вашему языку.

Изучив синтаксис конструкции try{...}catch(Exception $e){...}, узнав о возможности создавать собственные классы исключений, наследуя их от класса Exception и поверхностно осознав мощь оказавшегося в ваших руках механизма, дальше вы можете пойти по одному из двух путей:

• Начать тут же использовать исключения. Скажем, прикручивать их к системе, в которой они никогда не использовались. Или приколачивать их к проекту, в котором ООП и не пахнет. Или, что самое ужасное, пытаться использовать их повсеместно, особенно там, где это не нужно.
• Попытаться понять, где их применять, как делать это правильно, и зачем они нужны.

Недавняя статья о порядке инициализации членов класса вызвала весьма любопытную дискуссию, в которой, среди прочих, обсуждался вопрос, как правильно оформлять члены класса, хранить ли их по значению и организовывать конструктор так:

A::A(int x) : b(x) {}

Или хранить их по ссылке:

A::A(int x) { b = new B(x); }

Существует множество «за» и «против» для каждого из подходов, но в этой заметке мне бы хотелось сосредоточиться на вопросах обработки исключений.

Некоторые вещи иногда работают не так, как подсказывает интуиция. Это утверждение можно отнести к обработке исключений в Java. Далее — ситуации и примеры кода, которые отражают некоторые имеющиеся нюансы.

(Для начинающих)

Обрабатывать исключения — хорошая привычка, но если писать на все случаи деревья try-except, эти конструкции начинают повторяться, а код становится сложным и трудночитаемым. А ещё писать все обработки просот лень.

Чтобы обработка исключений не была болезненной, и чтобы уменьшить повторяемость кода, нужно пользоваться мощью и гибкостью Питона.

В предыдущей статье я предложил свести все «механизмы ошибок» к исключениям, поэтому логично будет объяснить, как правильно работать с исключениями в PHP.
Сначала поясню, почему я выбрал именно исключения, как механизм работы с ошибками:

1. Исключения — это гибкий, расширяемый метод обработки ошибок;
2. Это стандартизованный механизм – человеку, не работавшему с вашим кодом, не нужно будет читать мануал, чтобы понять, как обрабатывать ошибки. Ему достаточно знать, как работают исключения;
3. С исключениями гораздо проще находить источник ошибок, так как всегда есть стек вызовов (trace).

Сразу скажу, что в этой статье я не открываю Америку. Описаны стандартные принципы работы с исключениями плюс некоторые особенности, налагаемые PHP. Полезно будет почитать новичкам, хотя может быть и опытные разработчики найдут что-нибудь новое для себя.

Здравствуйте. Я планировал написать большую статью об управлении ресурсами в С++.
Но на практике, тема эта такая сложная и многогранная, что я хочу остановиться на определённой методике, которой пользуюсь сам. Данная методика не является спасением на все случаи жизни, но экономит много времени и нервов при работе с объектами. При этом, не является широко известной.

Недавно ковырял паттерны проектирования и попутно пытался переделать один проект на эксепшены. Из этого коктейля родилось несколько мыслей, которыми хочется поделиться с общественностью.

Всем привет. Сегодня я расскажу (и покажу) вам, как организована работа с файлами в Dyalog APL. Экспериментировать будем с «родной» файловой системой Dyalog – DCF, остальные файлы в данной статье не рассматриваются. Также будет затронута тема обработки исключений. Все опыты будут проводится на материале из прошлого топика. К сожалению, некоторые изображения хренового качества, прошу меня извинить, ибо не знаю хорошего хостинга картинок. Итак, поехали.

По служебной необходимости мне пришлось столкнуться с задачей создания клиента WCF-службы под Mono 2.6.7.
Всё вроде бы шло хорошо – клиент работал как под .NET, так и под Mono – до тех пор, пока я не занялся обработкой исключений, которые могут возникнуть в методах WCF-службы.
Проблемы начались тогда, когда мне понадобилось обработать моё собственное исключение, содержащее не только сообщение исключения, но и некоторую дополнительную информацию.
Я решил, что организую обработку исключительных ситуаций так, как это описано в статье «Exceptions through WCF» (http://habrahabr.ru/blogs/net/41638/) уважаемого Романа RomanNikitin.
В .NET клиент работал так, как надо, а вот при запуске под Mono возникла следующая ошибка:

Введение

Меня до глубины души задело заявление моего коллеги, что использовать исключения — это неправильно. А далее последовала череда объяснений: это медленно, это некрасиво, это неэффективно, это неудобно.

Многие программисты почему-то считают, что исключения и ошибки — это одно и то же. Кто-то постоянно кидает exception, кто-то через errorHandler превращает ошибки в исключения. Некоторые пытаются увеличить производительность, используя исключения. Но, на самом деле, exception и ошибки — это совершенно разные механизмы. Не надо одним механизмом заменять другой. Они созданы для разных целей.

Когда появился php5 с исключениями, а затем ZendFramework, который всегда кидает исключения — я не мог понять: чем же exception лучше моего любимого trigger_error()? Долго думал, обсуждал с коллегами и разобрался в этом вопросе. Теперь я чётко знаю, где использовать trigger_error(), а где throw new Exception().

В чём же принципиальная разница между ними?

Судя по всему, неделя исключений на хабре успешно наступила :). Накопив достаточную «подушку» кармы чтобы не бояться уйти в минус, я, пожалуй, тоже выскажу свое мнение по данному вопросу. Сразу оговорюсь, что мнение сугубо личное, основанное на небольшом практическом опыте коммерческой разработки: C++, Objective-C, C#, Java, Python, Ruby.

Просмотрев пост Коды возврата vs исключения и комментарии к нему, я заметил, что в обсуждении упущена одна нить, краткий тезис которой следующий: в некоторых языках такая проблема даже не стоИт, т.к. вопрос «что выбрать, коды возврата или исключения» в таком языке является низкоуровневым. Как, например, не стоит вопрос, каким образом реализовать конструкцию «foreach». Т.к. для программиста, использующего тот же «foreach», нет никакой разницы, использовали ли создатели языка while или for или что-то еще в имплементации данного оператора. Главное это паттерн, который представляет собой этот самый оператор.

Хватит рассуждать про foreach. Покажу непосредственно на примере два очень похожих друг на друга оператора, один из которых использует в качестве реализации «исключения», другой — «коды возврата».

Всем нам хорошо известен способ использования ключевого слова else совместно с if:

if x > 0: 
    print 'positive' 
elif x < 0: 
    print 'negative' 
else: 
    print 'zero' 

Однако в Python’е существует и несколько других, неизвестных большинству программистов, применений else.

Одним из самых замечательных и притягательных свойств языка Common Lisp является, безусловно, его система обработки исключений.

Более того, по моему, лично, мнению, подобный подход к исключениям является единственно правильным для всех императивных языков, и вот по какой простой причине:

Механизм «исключений»(или, как они называются в мире CL — conditions) в Common Lisp отделен от механизма раскрутки стека, а это, соответственно, позволяет обрабатывать любые всплывающие в программе исключительные(да и не только исключительные) ситуации прямо в том месте, где они возникли, без потери контекста выполнения программы, что влечет за собой удобство разработки, отладки, да и вообще, удобство построения логики программы.

Наверное, следует сказать, что Common Lisp Condition System, несмотря на свою уникальность в среде высокоуровневых языков программирования, очень близка известным многим разработчикам низкоуровневым средствам современных операционных систем, а именно: синхронным сигналам UNIX и, гораздо ближе, механизму SEH(Structured Exception Handling) из Windows. Ведущие реализации CL основывают такие элементы управления потоком вычислений, как механизм обработки исключений и раскрутка стека, именно на них.

Несмотря на отсутствие похожего механизма во многих других(если не всех) императивных языках программирования, он поддается реализации в более-менее вменяемом виде на большинстве из них. В данной статье я опишу реализацию на C#, по ходу дела разбирая в деталях саму концепцию данного подхода к «исключениям».

Итак, вы написали программу, запустили в отладчике — все хорошо, все нормально. Поставили в рабочий процесс — валится. Причем, в самых неожиданных местах.
Что делать?
Начинаем думать. Везде ставить try-catch… вычислительный блок будет здорово тормозить. Значит, надо сделать отладочную версию. Значит, вводим
#define __TRY__DEBUG__