C#: любой способ подавления ошибок компилятора, подобных подавлению предупреждающих сообщений?

у меня есть следующий код, который создает ошибку компилятора:

    Boolean IConvertible.ToBoolean(IFormatProvider provider)
    {
        ThrowHelper.ThrowInvalidCast(typeof(MyType), typeof(Boolean));
    }

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

Я понимаю, что могу удовлетворить компилятор глупым "возвращением true" после ThrowHelper вызова, но это кажется ненужным кодом. Я знаю, что могу подавлять предупреждающие сообщения, но когда я пытался использовать SuppressMessageAttribute это не мешает компилятору жаловаться. Любой способ подавить эту ошибку только для этого метода?

7
c# compiler-errors error-suppression

3 ответов

нет никакого способа подавить ошибку, кроме как исправить ее.

ошибка по своей природе указывает на то, что компилятор считает, что он не может генерировать допустимый код. Единственный способ подавить ошибки-исправить их. Просто добавьте return заявление, которое он хочет, а затем поднять вопрос на Microsoft Connect указывая, что вы считаете, что компилятор получает это неправильно.

Я подозреваю, однако, что это ожидаемое поведение, поскольку компилятор не знает что метод, который вы вызываете, всегда будет бросать и определить, что предсказуемым образом для любого возможного дерева вызовов будет сложно, если не невозможно (представьте, что вы вызвали цепочку из 20 методов, прежде чем завершить бросок).

6

вы можете иметь метод в ThrowHelper только создать исключение, а не фактически бросить его. 

Boolean IConvertible.ToBoolean(IFormatProvider provider)
{
    throw ThrowHelper.CreateInvalidCast(typeof(MyType), typeof(Boolean));
}

Это, вероятно, приведет к лучшей трассировке стека: это будет указывать на ToBoolean, а не на ThrowInvalidCast.

7

простое упражнение мозга, почему запрошенная функция может привести к проблемам. Представь, что ThrowHelper.ThrowInvalidCast определен на каком-либо 3-участник библиотека. Вы можете знать, что метод всегда бросает и сообщает об этом компилятору, или очень продвинутый статический анализатор может определить, что метод всегда бросает на данный момент код компилируется.

теперь какой-то другой разработчик развертывает обновленную версию этой библиотеки. Теперь метод не всегда бросает. Все внезапно возникает случай, когда ваш метод не имеет обратного пути. Просто для обработки этого случая компилятор (или среда выполнения) должен будет включить план резервного копирования, что делать в такой ситуации. Довольно много накладных расходов для чего-то, что можно легко исправить, написав правильный код.

UPDATE: теоретически, C# может быть расширен, чтобы разрешить методы без пути возврата. Эрик Липперт упомянул об этом в комментарии к ответу Джона Скита здесь:

A " никогда" метод будет просто методом void, которому не разрешено иметь достижимую конечную точку или любые операторы return. Это решает проблему во время компиляции. Во время выполнения верификатор обязан убедиться, что методы действительно правильно реализуют семантику возвращаемого типа; верификатор может аналогичным образом определить, что нет инструкций возврата и что конечная точка недоступна.

3