2010-11-03 5 views
25

В Java вы явно определяете, какие исключения выбрасываются с использованием ключевого слова «броски». Таким образом, любой, кто звонит вашему методу, знает, что поймать.C# явно определяет, какие исключения выбрасываются

Есть что-то в C#? Если нет, то как я узнаю, какие исключения поймать, или как я могу сообщить другим, какие исключения поймать?

Кроме того, если я определяю интерфейс, есть ли способ сказать: «methodX() должен вызывать это исключение при ошибке»?

+0

Я предполагаю, что версия .NET Framework будет иметь здесь значение, но в версиях, которые я использую, ответ: вы правильно документируете потенциальные исключения, и нет - никоим образом не принудительно вводить тип исключенного (не более захват всех исключений за пределами и повторная упаковка их в ваш предпочтительный тип). Это не просто исключения, которые вы могли бы генерировать в методе, есть и любые, что вы допускаете пузырь. – Rudu

ответ

32

Там нет ничего эквивалент в C#: The Trouble with Checked Exceptions

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

+1

Интересная, но неправильная статья. – JeremyP

+0

очень интересно читать –

+1

@JeremyP как это неправильно? – dbkk

3

C# не поддерживает это. (Не то, что я знаю все равно). Что вы можете сделать, это использовать комментарии Xml, чтобы при вызове методов эти данные будут отображаться intellisense.

2

Насколько я знаю, в C# нет объявления throws, вы можете документировать свой метод, указывая на то, что он генерирует исключение, но без принудительной обработки ошибок.

+0

lol time мне потребовалось, чтобы написать это еще 2 человека уже были опубликованы! – DeliveryNinja

8

Эта функция недоступна на C#. Вы можете сделать правильную XML-документацию (3 слэша ///) и указать, какие исключения выбрасываются.

Это будет воспринято механизмом IntelliSense и будет видимым для пользователей класса/метода до их использования.

2

C# не поддерживает проверенные исключения. Разработчики языка рассматривают проверенные исключения в том, как java использует их плохую идею.

Some workarounds

10

C# /. Сеть не имеет проверяемые исключения, они оказались менее полезными в крупномасштабных системах, чем первая мысль. Во многих проектах время для поддержки спецификаций исключений проверки было намного больше, чем время отладки, сэкономленное за счет их наличия.

Проверено Исключения выглядят как хороший идеал, пока у вас не будет методов, которые могут принимать делегаты или вызовы в объект, в который вы проходите. Возьмем простой случай, метод Sort() в списке не может знать, какие исключения он будет бросать, поскольку он не знает, какие исключения сравнивает метод Compar() на отсортированных объектах.

Таким образом, спецификация исключений, которые метод может бросать, должна иметь возможность включать информацию о том, как исключения заполняются из прохода в объектах и ​​делегатах. Никто не знает, как это сделать!

Однако есть инструменты, которые вы проверяете, если вы ловите все исключения - см. Exception Hunter от Red Gate. Я лично не вижу большой ценности в этом инструменте, однако, если вам нравятся проверенные исключения, вы можете найти их полезными.

Смежные вопросы