Комментарии 22
Если использовать данную аннотацию, то для компиляции кода не понадобится ли установленный ReSharper?
Нет, не понадобится, аттрибуты для аннотации должны быть описаны в проекте.
Я немного промахнулся, отвечая на ваш вопрос. =)
Аннотации в XML-файлах нужны только анализатору ReSharper'а. На сборку проекта они никак не влияют. Будет ли у Вас код проаннотирован контрактами или нет, Вы получите сборки, совершенно одинаковые по своей функциональности в рантайме.
То есть, вы можете спокойно скопировать JetBrains.Annotations.dll в папку с проектом/решением или написать реализацию атрибутов в своем проекте. А дальше — MSBuild, NAnt или еще что угодно. Им не нужно знать об аннотациях. =)
Надеюсь, я правильно понял Ваш вопрос.
То есть, вы можете спокойно скопировать JetBrains.Annotations.dll в папку с проектом/решением или написать реализацию атрибутов в своем проекте. А дальше — MSBuild, NAnt или еще что угодно. Им не нужно знать об аннотациях. =)
Надеюсь, я правильно понял Ваш вопрос.
А вот такой вопрос — можно ли запустить решарпер в режиме глубокого анализа? Т.е. то что описывается, но чтобы он вплоть до фреймворка разбирал и проверял что оттуда возвращается\кидается и выдавал hint'ы.
Т.е. я например на билдовой машине (или на ночь на свое) запускаю анализ, ессесно машина грузится по полной, работать на ней нельзя, но утром следующего дня получаю подробный список возможных лакун и мест, где стоит «впилить» дополнительные проверки или хотя бы сделать fallback'и в случае неисправимых ситуаций.
Т.е. я например на билдовой машине (или на ночь на свое) запускаю анализ, ессесно машина грузится по полной, работать на ней нельзя, но утром следующего дня получаю подробный список возможных лакун и мест, где стоит «впилить» дополнительные проверки или хотя бы сделать fallback'и в случае неисправимых ситуаций.
Нет, в текущей реализации алгоритма это сделать невозможно. Но планируется плагин, который даст возможность делать примерно то, что вы описали — запускать на ночь анализ, который расставляет атрибуты NotNull/CanBeNull в проекте автоматически.
Автоматическая расстановка не так интересна, как просто лог «потенциальных проблем», ведь в лог входят не только NullReference но и куча других исключений которые могут выкидывать методы фреймворка.
NullReference это конечно тоже хорошо, хотя я лично против того что что-то будет расставлять аттрибуты в коде — если надо — в Xml файле и во временный каталог решарпера — не у всех он стоит и засорять код — не хочется.
NullReference это конечно тоже хорошо, хотя я лично против того что что-то будет расставлять аттрибуты в коде — если надо — в Xml файле и во временный каталог решарпера — не у всех он стоит и засорять код — не хочется.
Никто не будет расставлять атрибуты без вашего ведома. Это ваше право использовать или не использовать атрибуты Решарпера. Но, если вам захочется проаннотировать ими уже имеющийся проект, то почему бы не сделать это автоматически в тех местах, где машина может их вывести. Именно для этой цели разрабатывается упомянутый мной плагин.
Можете описать подробнее, какой лог потенциальных проблем вы хотите получить?
Можете описать подробнее, какой лог потенциальных проблем вы хотите получить?
Отображение в виде подсказок информации о том, какие исключения могут вылететь из вызова метода — например при работе с файлам — нет проверки что есть права доступа, что файл не залочен…
Вот например — msdn.microsoft.com/en-us/library/b9skfh7s.aspx File.Open() может выкинуть 9 разных задокументированных исключений.
Хотелось бы следующего ( не уверен вообще реализуемо ли, но «хотелка» она такая вот) — в логе видеть данные:
метод File.Open, перечень исключений которые он выкидывает, и напротив каждого — состояние — вылетит ли оно выше или оно обрабатывается как-либо (условия входа в ветку проверяют на определенные кондишены). Т.е. если перед вызовом — стоит проверка на существование файла — напротив DirectoryNotFoundException и FileNotFoundException — пометка — не вылетит. А вот напротив UnauthorizedAccessException — пометка что вылететь может, т.к. нет проверки прав на доступ к файлу.
Что-то типа такого…
Понятно что разбор этого всего дела — будет тяжел и утомителен, но при ревью кода можно принимать во внимание рекомендации решарпера или хотя бы обращать более пристальное внимание на то, что он говорит.
По сути — некий анализ выполнения программы по разным сценариям. Что-то типа такого Microsoft делает в Pex, насколько я понимаю, только там они сразу генерят тесты с «хитрыми» значениями, а тут уведомления\лог получить хочется (в человеко-машино-читаемом формате типа Xml — вообще супер).
Вот например — msdn.microsoft.com/en-us/library/b9skfh7s.aspx File.Open() может выкинуть 9 разных задокументированных исключений.
Хотелось бы следующего ( не уверен вообще реализуемо ли, но «хотелка» она такая вот) — в логе видеть данные:
метод File.Open, перечень исключений которые он выкидывает, и напротив каждого — состояние — вылетит ли оно выше или оно обрабатывается как-либо (условия входа в ветку проверяют на определенные кондишены). Т.е. если перед вызовом — стоит проверка на существование файла — напротив DirectoryNotFoundException и FileNotFoundException — пометка — не вылетит. А вот напротив UnauthorizedAccessException — пометка что вылететь может, т.к. нет проверки прав на доступ к файлу.
Что-то типа такого…
Понятно что разбор этого всего дела — будет тяжел и утомителен, но при ревью кода можно принимать во внимание рекомендации решарпера или хотя бы обращать более пристальное внимание на то, что он говорит.
По сути — некий анализ выполнения программы по разным сценариям. Что-то типа такого Microsoft делает в Pex, насколько я понимаю, только там они сразу генерят тесты с «хитрыми» значениями, а тут уведомления\лог получить хочется (в человеко-машино-читаемом формате типа Xml — вообще супер).
Получается продвинутая спецификация исключений, как в Java. =)
В сценарии, описанном вами, придется использовать очень много информации о вызываемом коде. В том числе нужно ввести пометки о том, что методы не меняют состояния объекта между проверками и местами, где может быть выброшено исключение в случае отсутствия этих проверок. Средствами Решарпера нельзя провести настолько глубокий анализ.
Да и такие сценарии весьма конкретны и сравнительно редки. Не то что подстановка в ненулевой параметр метода переменной, которая может внезапно оказаться null'ом.
В сценарии, описанном вами, придется использовать очень много информации о вызываемом коде. В том числе нужно ввести пометки о том, что методы не меняют состояния объекта между проверками и местами, где может быть выброшено исключение в случае отсутствия этих проверок. Средствами Решарпера нельзя провести настолько глубокий анализ.
Да и такие сценарии весьма конкретны и сравнительно редки. Не то что подстановка в ненулевой параметр метода переменной, которая может внезапно оказаться null'ом.
Подсветка «Possible 'NullReferenceException'» при использовании метода переменной iAmNullSometimes в таком случае не появляется.
Наоборот? Атрибут [CanBeNull] был добавлен ради подсветки.
Алексей, скажите, а как лучше аннотировать такой метод?
По идее надо как assertion, так как он ведет себя аналогично Contract.Assert, но это не подходит, потому что нет условия как такового.
void Guard.IsNotNull(object value, string name);По идее надо как assertion, так как он ведет себя аналогично Contract.Assert, но это не подходит, потому что нет условия как такового.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ReSharper: Анализ на NullReferenceException и контракты для него