Я знаю Googling. Я могу найти подходящий ответ, но я предпочитаю слушать ваши личные (и, может быть, технические) мнения.
В чем основная причина разницы между Java и С# при метании исключений?
В Java подпись метода, который генерирует исключение, должна использовать ключевое слово "throws", а в С#, которое вы не знаете во время компиляции, если может быть выбрано исключение.
Поскольку ответ на проверенные исключения почти всегда:
try {
// exception throwing code
} catch(Exception e) {
// either
log.error("Error fooing bar",e);
// OR
throw new RuntimeException(e);
}
Если вы действительно знаете, что есть что-то, что вы можете сделать, если какое-то конкретное исключение выбрано, вы можете его поймать, а затем обработать, но в противном случае это просто заклинания, чтобы успокоить компилятор.
Нейтраль при проверенных исключениях
"С# в основном молчат на проверке исключение выпуск. Когда-то лучше решение известно - и поверьте мне, мы продолжайте думать об этом - мы можем пойти назад и на самом деле место".
Версии с проверенными исключениями
"Добавление нового исключения в броски в новой версии ломает клиент код. Это похоже на добавление метода к интерфейс. После публикации интерфейс, это для всех практических цели неизменяемы,..."
"Забавно, как люди думают, что важная вещь об исключениях обрабатывая их. Это не важная вещь об исключении. В хорошо написанное приложение там отношение десяти к одному, на мой взгляд, попробуйте, наконец, попытаться поймать. Или в С#,
using, которые например, попробовать наконец. "
Масштабируемость проверенных исключений
"В небольших проверенных исключениях очень заманчиво... Беда начинается, когда вы начинаете строить большие системы, в которых вы разговариваете с четырьмя или пять различных подсистем. каждый подсистема выбрасывает от четырех до десяти исключения. Теперь, каждый раз, когда вы поднимаетесь лестнице агрегации, у вас есть эта экспоненциальная иерархия ниже вас исключений, с которыми вам приходится иметь дело. В итоге вам нужно объявить 40 исключения, которые вы можете бросить... Это просто воздушные шары из-под контроля".
В своей статье " Почему С# не имеет спецификаций исключений?, Anson Horton (Visual С# Program Manager) также перечислены следующие причины (см. статью для подробностей о каждой точке):
Интересно отметить, что С#, тем не менее, поддерживает документацию об исключениях, заданных данным методом, с помощью тега <exception> и компилятор даже берет на себя труд убедиться, что ссылочный тип исключения действительно существует. Однако на сайтах вызовов не используется проверка или использование метода.
Вы также можете посмотреть в Exception Hunter, который является коммерческим инструментом Red Gate Software, который использует статический анализ для определения и отправки исключений, создаваемых методом и которые потенциально могут быть неактивными:
Exception Hunter - новый анализ инструмент, который находит и сообщает набор возможные исключения Ваши функции может бросить - прежде чем вы даже отправляете. С его помощью вы можете найти необработанные исключений легко и быстро, вплоть до строка кода, которая бросает исключения. Когда у вас есть результаты, вы можете решить, какие исключения необходимы для обработки (с некоторым исключением код обработки), прежде чем вы приложение в дикую природу.
Наконец, Брюс Эккель, автор Мышление в Java, есть статья под названием " Требуется ли Java Checked Exceptions?", что тоже стоит прочитать, потому что вопрос о том, почему проверены исключения не существует в С#, как правило, используется для сравнения с Java.
Основная философия дизайна С# заключается в том, что на самом деле catching exceptions редко бывает полезным, в то время как очистка ресурсов в исключительных ситуациях очень важна. Я считаю справедливым сказать, что using (шаблон IDisposable) является их ответом на проверенные исключения. Подробнее см. В [1].
К тому времени, когда был разработан .NET, Java довольно давно проверял исключения, и эта функция была в лучшем случае рассмотрена разработчиками Java как спорная спорный. Таким образом, разработчики .NET выбрали, чтобы не включать его на язык С#.
В принципе, нужно ли обрабатывать исключение или нет, это свойство вызывающего, а не функции.
Например, в некоторых программах нет значения при обработке IOException (рассмотрите специальные служебные программы командной строки для выполнения хруста кривых данных, они никогда не будут использоваться "пользователем", они используются специалистами специалистами). В некоторых программах существует ценность в обработке IOException в точке "рядом" с вызовом (возможно, если вы получите FNFE для своего конфигурационного файла, вы вернетесь к некоторым значениям по умолчанию или посмотрите в другом месте или что-то в этом природа). В других программах вы хотите, чтобы он пузырился задолго до его обработки (например, вы можете отказаться от него до тех пор, пока он не достигнет пользовательского интерфейса, после чего он должен предупредить пользователя о том, что что-то пошло не так.
Каждый из этих случаев зависит от приложения, а не от библиотеки. И все же, с проверенными исключениями, именно эта библиотека принимает решение. Библиотека IO Java принимает решение о том, что она будет использовать проверенные исключения (которые настоятельно рекомендуют обрабатывать этот локальный вызов), когда в некоторых программах лучшая стратегия может быть нелокальной обработкой или вообще не обрабатываться.
Это показывает реальный недостаток с проверенными исключениями на практике, и это гораздо более фундаментально, чем поверхностный (хотя и важный) недостаток, который слишком много людей напишет глупые обработчики исключений, чтобы заставить компилятор заткнуться. Проблема, которую я описываю, является проблемой, даже когда опытные, добросовестные разработчики пишут программу.
Интересно, что ребята из Microsoft Research добавили проверенные исключения в SpeС#, их надмножество С#.
Сам Андерс отвечает на этот вопрос в этот эпизод радиоподкаста по разработке программного обеспечения
Я перешел с Java на С# из-за смены задания. Сначала меня немного беспокоило разницу, но на практике это не повлияло.
Возможно, это потому, что я пришел из С++, у которого есть объявление исключения, но оно не используется обычно. Я пишу каждую строку кода, как если бы она могла быть выбрана - всегда используйте использование вокруг одноразового использования и думайте об очистке, которую я должен сделать в конце.
В ретроспективе распространение объявления throws в Java на самом деле ничего не принесло мне.
Мне хотелось бы сказать, что функция определенно никогда не бросает - я думаю, что это было бы более полезно.
Помимо ответов, которые уже были написаны, не проверенные исключения часто помогают вам во многих ситуациях. Проверенные исключения делают сложнее реализовать дженерики, и если вы прочтете предложения о закрытии, вы заметите, что каждое предложение о закрытии должно работать над проверенными исключениями довольно уродливым способом.
Я иногда пропускаю проверенные исключения в С#/. NET.
Я полагаю, кроме Java нет другой заметной платформы. Возможно, ребята .NET просто пошли с потоком...