Что такое проверенные исключения в Java/С#?

Ответ 1

Исключенные исключения - это исключения, которые компилятор требует, чтобы вы каким-то образом обрабатывали.

В Java проверенные исключения: Throwable, которые не являются RuntimeException, Error или один из их подклассов.

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

Таким образом, Java разработан таким образом, что программа должна каким-то образом синтаксически обрабатывать исключение. Это может быть с блоком catch или каким-то образом путем переустановки исключения.

С# не имеет проверочных исключений. Они решили оставить эту проблему разработчикам приложений (). Проверенные исключения противоречивы, потому что они могут сделать код многословным, в то время как разработчики иногда обрабатывают их тривиально пустым блоком catch. Кроме того, это может быть произвольно, какие стандартные библиотечные методы бросают проверенные исключения. Например, почему File.delete (новый API Java 7 делает это по-другому) throw IOException?

Еще одна проблема, которую Хейлсберг отметил в этом интервью, - это вариантность. Добавление проверенного исключения в предложение throw заставляет весь код, используя этот метод, модифицироваться и перекомпилироваться.

Ответ 2

В Java исключение checked (как правильно указывает Матфей Флашен) - это исключение, которое требует от вас компилятор. Это исключения, объявленные в определениях функций (например, function bob() throws ImNotBobException { ... }, чтобы сказать, что вызов этой функции может вызывать это исключение - например, NumberFormatException при разборе целого числа или IOException при записи в файл.

Однако некоторые исключения могут быть выбраны из неизвестных или неожиданных мест, которые просто непрактичны для обработки на каждом уровне, поэтому компилятор не требует от вас обработки этих данных. Это исключенные исключения. Их можно выбросить из разных мест, которые не объявляют их бросать (часто, пытаясь вызвать метод на объекте, когда этот объект еще не был инициализирован, т.е. Имеет значение null - это приведет к NullPointerException.)

Надеюсь, что это поможет.

Ответ 3

Исключенные исключения - это исключения, которые требуют, чтобы какой-либо "потребляющий" класс должен был кодировать, который явно проверяет (и, надеюсь, обрабатывает) исключение.

Например, если класс Apple имеет метод Eat(), который включает проверенное исключение WormFound, то для любого кода, который вызывает этот метод, явно будет иметь catch для этого исключения.

В качестве побочной заметки это функция Java, а не С#.

(В момент создания С# плюсы проверенных исключений были не столь очевидны в глазах команды С#, поэтому они не были включены.)

Ответ 4

Обратите внимание: это ответ с моей личной (довольно перфекционистской) точки зрения и моего личного опыта.

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

Я выучил J2SE1.3 в возрасте 15 лет (на рубеже веков) в качестве первого языка программирования в свое свободное время, после того, как он был напуган C и C++ (да, управление памятью - кажется, дальнейшая эволюция только сделал разработчиков еще более ленивыми, или, по крайней мере, это дало им возможность стать ленивее).. Недавно я поднял его снова с целью стать Java-разработчиком (предпочтение, очевидно, связано с моим предыдущим опытом). Я изучал Java 8, и, по моему личному мнению, я достаточно опытен в этом, в том числе и в том, что касается общего понимания, которое затмевает языки и языковые особенности.

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

Я уверен, что у вас могут быть дерьмовые разработчики для каждого мыслимого языка программирования, но я вижу много дерьмового кода на ежедневной основе. Почему? По моему личному мнению? Потому что С# это позволяет. Он компилируется и запускается. Странные вещи случаются, но никто не заботится. Исключения бросаются повсюду. Но они каким-то образом попадаются по пути, на самом деле не обрабатываются, так что никого не волнует... Разработчики не вынуждены смотреть на возможные ошибки. Так что это оставлено на усмотрение тестировщиков... Люди, которые еще меньше знают о том, что происходит за кулисами (мы не можем проверить код и понять его, оставьте в покое, что кто-то в такой ленивой среде документировал что-нибудь...) подтвердить, что продукт делает то, что должен делать...

Правда, Java может потребовать "больше работы" для выполнения той же задачи. Но с точки зрения птичьего полета, с точки зрения обеспечения качества, по крайней мере, он обеспечивает некоторый контроль. В некотором контроле .NET не хватает, по крайней мере, того, что я видел до сих пор. Похоже, в .NET легче разрабатывать (из того, что я собрал), но из-за этой роскоши, на мой взгляд, ошибки вносятся легче. И качеством кода пренебрегают. По крайней мере, в среде, где я работаю.

Тест разработчика: он компилируется, работает, мой счастливый поток работает? Круто!

Мой тест: он компилируется, он запускается, ваш счастливый поток работает, мои дюжины тестовых примеров не вызывают сбой приложения, но ваш код компилируется и запускается, и дает очень нежелательные результаты, в целом противоречащие тому, что было задано... Но так как требования Я не могу точно сказать, что он делает то, что должен делать... "Но, эй, он скомпилирован, он запустился и не вылетел, верно?"...

Я часто слышу оправдание в случае неожиданного (и часто расплывчатого, трудно отлаживаемого исключения): "Но эти данные ДОЛЖНЫ быть предоставлены!"... Нет, ваша задача предположить, что это НЕ БУДЕТ, и написать надежный код! Тот факт, что он компилируется и запускается, не означает, что это хорошо... Мне также нравится иметь возможность читать код в режиме онлайн в текстовом формате, зная, что он будет делать и что ожидается, не полагаясь на сторонние инструменты для скажите, какого типа будет эта переменная, или почему метод неожиданно остановится из-за непроверенного исключения.

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

Ответ 5

(несколько лет спустя, для людей, прибывающих сюда через авиакомпании Google)

Проверенные исключения были ошибкой в дизайне языка Java. СРОК. Всякий раз, когда вы обнаруживаете проверенное исключение, заключите их в непроверенное исключение (возможно, RuntimeException).

К сожалению, из-за маркетинговых проблем сначала Sun, а затем Oracle не смогли открыто признать свою ошибку.

Во время создания Java обработка исключений была неясной. Java-дизайнеры наивно полагали, что принуждать разработчиков проверять исключения во время компиляции - хорошая идея. Хотя это выглядит интуитивно правильным, это оказалось анти-паттерном, похожим на использование "GOTO". Это никогда не работало на практике и вызывает много проблем. Исключения должны обрабатываться в "главном цикле" или "контроллере", поскольку в противном случае, если бы они могли обрабатываться внутри функции, вызывающей ошибку, они не были бы исключением, а предполагаемой ошибкой, которая должна поддерживаться нормальное возвращаемое значение API. Исключение, по своей природе, является чем-то, что не рассматривается, и это не допускает нормального выполнения кода.

Обратите внимание, например, на то, что Spring, "стандартная" среда Java для разработки корпоративных приложений, просто ограничивает превращение проверенных исключений в непроверенные исключения.

Для справки: Kotlin, разработанный экспертами по Java и Scala и один из самых популярных языков в опросах stackoverflow), полностью исключил проверенные исключения. Более подробная информация доступна по адресу: 2