Здравствуйте, VladD2, Вы писали:

VD>Нет, см. выше. Конечно все проверки — это вообще сфера предпочтений и стратегий, но у нас принята стратегия в которой Assert и темболее Debug... ставится для того чтобы проверить свои предполжения. А когда ты пишишь метод который может быть вызван черт знает откуда, черт знает кем, то неверные входные условия являются исключительной ситуацией для функции, а значит должны генерировать исключения.

Хорошо, я не знал, что у вас используется такая стратегия. Буду впредь придерживаться того же.

VD>Конкретнее пожалуйста. Что значит "некорретные"? И в следствии чего они могут приходить.

Пример. Переименовываешь файл, нажимаешь Del, стирается полное имя файла, вылетает необработанное исключение, студия закрывается с ошибкой. Какое здесь должно быть поведение? Если придерживаться стратегии, которую ты описал, так и должно быть. Меня, как конечного пользователя, это сильно напрягает. Как разработчик, причину я устранить не могу, но замазыванием я спасаю студию, пусть и с вылетом где-то First-chance exception. И где компромисс? Ситуация чисто теоретическая, я просто хочу знать, как в ней быть, чтобы впредь ничего не сломать.

N>> Я отловил пару раз NullReferenceException и поставил проверки.

VD>NullReferenceException не повод замазывать ошибку. Он скорее всего является следсвием другой ошибки. Вот ее и надо устранять. А проверки на null не должны быть связаны с тем что где-то там есть NullReferenceException. Они должны быть частью логики работы программы. Поэтому я и спрашиваю в чем эта логика. Так как мне кажется, что в некоторых местах эта логика нарушена или как минимум усложнена.

Опять привожу для примера ситуацию выше. Замазыванием ошибки я сделал работу конечного пользователя более комфортной. В чем я неправ? Да, я не устранил причину, но до некоторых причин докопаться очень тяжело или вообще нереально, т.к. они вызываются где-то из недр студии.

VD>Здесь можно сказать все ОК. Только зачем делать отрицающее условие? Оно усложняет чтение. В таких случаях нужно писать:
VD>

VD>if (String.IsNullOrEmpty(location))
VD>    _projectLocation = Path.GetDirectoryName(fileName);
VD>else
VD>    _projectLocation = location;
VD>

VD>Отрицающие условия хуже читаются и в if/else и ?: их лучше не использовать.

Хорошо. Так впредь и буду делать.

VD>

VD>public bool IsFileInProject(string filePath)
VD>{
VD>    if (String.IsNullOrEmpty(filePath))
VD>    {
VD>        return false;
VD>    }
VD>    return _filesMap.ContainsKey(filePath);
VD>}
VD>

VD>Вот здесь уже большой вопрос. Я не представляю себе шататной ситуации когда путь к файлу будет пустым. Хотя бы имя то у него должно быть? А раз так тут надо вставлять проверки с возбуждением исключеий. Или хотя бы ничего не делать.

Ситуацию я описал выше.

VD>Заметь, даже если не ставить проверки, то функция ContainsKey() класса Dictionary проверит аргументи и выдаст исключение ArgumentNullException. Твой же код скроет ошибку.

ArgumentNullException вывалит студию.

VD>

VD>private static NemerleFileNodeProperties GetNodeProperties(IVsHierarchy hierarchy, uint itemID)
VD>{
VD>    if (hierarchy == null)
VD>    {
VD>        return new NemerleFileNodeProperties(null);
VD>    }
VD>    object propertyValue;
VD>    int    hr = hierarchy.GetProperty(itemID, (int)__VSHPROPID.VSHPROPID_BrowseObject, out propertyValue);

VD>    if (hr != VSConstants.S_OK)
VD>        throw new ArgumentException("Can't obtain VSHPROPID_BrowseObject for item with ID " + itemID, "itemID");

VD>    FileNodeProperties properties = propertyValue as FileNodeProperties;
VD>    if (properties != null)
VD>    {
VD>        return new NemerleFileNodeProperties(properties.Node);
VD>    }
VD>    return new NemerleFileNodeProperties(null);
VD>}
VD>

VD>Тут не ясно. На лицо изменение поведения метода, но есть ли в этом смысл? Или это очередная замазка другой проблемы?

Нет, не замазка. Смысл есть. Единственное, не уверен насчет new NemerleFileNodeProperties(null). Здесь надо кидать исключение, но не знаю какое.

VD>Ставить проверки чтобы что-то не вываливалось категорически не надо! Если ты не в силах понять причину проблемы, то просто опиши ее в этом форуме или добавь описание в баг-трекер. При этом обясни как воспроизвести эту ошибку. И тогда мы уже вместе решим что с ней делать.

Ладно.