Почему исключения не проверяются в .NET?

Question

Я знаю, Гуглю, я могу найти подходящий ответ, но я предпочитаю прислушиваться к вашим личным (и, возможно, техническим) мнениям.
В чем основная причина различия между Java и C # в создании исключений?
В Java сигнатура метода, который выбрасывает исключение, должна использовать ключевое слово throws, тогда как в C # во время компиляции вы не знаете, может ли быть выброшено исключение.

Answer 1

В статье Проблема с проверенными исключениями и в собственном голосе Андерса Хейлсберга (дизайнера языка C #) есть три основные причины, по которым C # не поддерживает проверенные исключения, так как они найдены и проверены в Java :

• Нейтрально при проверенных исключениях

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

• Управление версиями с проверенными исключениями

  «Добавление нового исключения в броски пункт в новой версии ломает клиента код. Это как добавить метод к интерфейс. После того, как вы опубликуете интерфейс, это для всех практично цели неизменны,… ”

  «Забавно, что люди думают, что важная вещь об исключениях справиться с ними. Это не важная вещь об исключениях. В хорошо написанное приложение есть соотношение десять к одному, на мой взгляд, из попробуй наконец попробовать поймать. Или в C #, using заявления, которые как, наконец, попробовать. "

• Масштабируемость проверяемых исключений

  «В небольших, проверенных исключениях очень заманчиво ... беда начинается, когда вы начинаете строить большие системы, где вы говорите с четырьмя или пять разных подсистем. каждый подсистема выбрасывает четыре-десять исключения. Теперь, каждый раз, когда вы поднимаетесь лестница агрегации, у вас есть эта экспоненциальная иерархия ниже вас исключений, с которыми вам приходится иметь дело. Вы в конечном итоге должны объявить 40 исключения, которые вы могли бы бросить.… Он просто выходит из-под контроля ».

В своей статье « Почему C # не имеет спецификаций исключений? », Anson Horton (менеджер программ Visual C #) также перечисляет следующие причины (подробности см. В статье). по каждой точке):

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

Интересно отметить, что C #, тем не менее, поддерживает документирование исключений, сгенерированных данным методом через тег <exception>, и компилятор даже пытается проверить, что ссылочный тип исключения делает действительно существует. Однако на сайтах вызовов или при использовании метода проверки не выполняются.

Вы также можете захотеть взглянуть на Охотник за исключениями , который является коммерческим инструментом Red Gate Software , который использует статический анализ для определения и сообщения об исключениях, генерируемых методом и которые потенциально могут остаться незамеченными:

Исключение Охотник - это новый анализ инструмент, который находит и сообщает набор возможные исключения ваших функций может бросить - еще до того, как отправишь. С его помощью вы можете найти необработанные легко и быстро исключения, вплоть до строка кода, которая бросает исключения. Как только у вас есть результаты, Вы можете решить, какие исключения нужны быть обработанным (за некоторым исключением обработки кода), прежде чем выпустить приложение в дикую природу.

Наконец, Брюс Экель , автор Thinking in Java , имеет статью под названием « Нужны ли в Java проверенные исключения? », которая может стоить чтение также потому, что вопрос о том, почему в C # нет проверенных исключений, обычно укореняется в сравнении с Java.

Answer 2

Поскольку ответ на проверенные исключения почти всегда:

try {
  // exception throwing code
} catch(Exception e) {
   // either
   log.error("Error fooing bar",e);
   // OR
   throw new RuntimeException(e);
}

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

Answer 3

Основная философия проектирования C # заключается в том, что на самом деле отлов исключений редко бывает полезен, тогда как очистка ресурсов в исключительных ситуациях весьма важна. Я думаю, будет справедливо сказать, что using (шаблон IDisposable) является их ответом на проверенные исключения. См. [1] для более подробной информации.

1. http://www.artima.com/intv/handcuffs.html

Answer 4

К тому времени .NET был разработан, Java проверил исключения в течение достаточно долгого времени, и эта функция рассматривалась разработчиками Java в лучшем случае, как противоречивым 1005 * противоречивым, Таким образом, дизайнеры .NET выбрали , чтобы не включать его в язык C #.

Answer 5

По сути, обработка или исключение - это свойство вызывающей стороны , а не функции.

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

Каждый из этих случаев зависит от приложения , а не от библиотеки . И все же, с проверенными исключениями, именно библиотека принимает решение. Библиотека Java IO принимает решение, что она будет использовать проверенные исключения (которые настоятельно рекомендуют обработку, которая является локальной для вызова), когда в некоторых программах лучшей стратегией может быть нелокальная обработка или вообще отсутствие обработки.

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

Answer 6

Интересно, что ребята из Microsoft Research добавили проверенные исключения в Spec # , их расширенный набор C #.

Answer 7

Сам Андерс отвечает на этот вопрос в этом эпизоде ​​ радио-подкаста по программной инженерии

Answer 8

Иногда я пропускаю проверенные исключения в C # /. NET.

Полагаю, кроме Java, ни на одной известной платформе их нет. Может быть, ребята .NET просто плыли по течению ...

Answer 9

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

Answer 10

Я перешел с Java на C # из-за смены работы. Сначала я немного беспокоился о разнице, но на практике это не имело значения.

Может быть, это из-за того, что я пришел из C ++, в котором есть объявление исключения, но оно обычно не используется. Я пишу каждую строчку кода, как если бы он мог генерировать - всегда использую использование вокруг Disposable и думаю об очистке, которую я должен сделать в конце концов.

Оглядываясь назад, можно сказать, что распространение объявления throws в Java ничего мне не дало.

Я хотел бы сказать, что функция определенно никогда не генерирует - я думаю, это было бы более полезно.