Почему Java-предложение «throws» (в объявлении метода) не включено в C #?

Question

Почему условие Java "throws" (в объявлении метода) не включено в C #?

Answer 1

Андерс Хейлсберг (ведущий архитектор C #) объясняет это в этом интервью:

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

Answer 2

(В дополнение к несколько определенному ответу Патрика.)

Проверенные исключения в Java - очень спорная проблема. Я любил их и очень скучал по ним, когда писал C #. Мне казалось, что я ехал без ремня безопасности. Теперь, они раздражают меня ... потому что, хотя они звучат как хорошая идея в теории, они определенно вызвали у меня много горя, но не принесли ощутимой пользы. Я не помню, чтобы когда-либо встречал ошибку в коде C #, из-за которой проверка исключений спасла бы меня. Это не значит, что этого не может быть, но со мной этого не произошло.

Раздражает то, что в некотором смысле все еще кажется, что C # слишком слаб, но подход Java не совсем правильный. Как будто есть лучшее решение, которое ждет своего открытия, и попытка Java была хорошим экспериментом, но она не вполне сработала.

Answer 3

Я думаю, что проверенные исключения как языковая функция выявляют некоторые культурные различия между Microsoft и Sun.

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

Да, да, я знаю, что Microsoft делает серверное программное обеспечение. Тем не менее, Office и Windows НАМНОГО больше по доходам, чем Windows Server и Exchange.

Я думаю, будет справедливо сказать, что большинство программ, написанных на .NET (и тем более на VB 6), являются клиентскими программами. Конечно, большая часть этого - веб-программное обеспечение, которое работает на веб-сервере, но большая часть этого действительно ... «веб-приложения клиентского типа». Я бы сказал, что большинство веб-приложений больше похожи на Word, чем на Exchange.

И да, я знаю, что есть сервисы WCF и SOAP и тому подобное, но обычно это просто "промежуточное ПО" для "клиентского" типа вещей.

С другой стороны, Sun - это, прежде всего, серверная компания. Их программное обеспечение не является самым лучшим, когда дело доходит до пользовательского интерфейса (это не так уж мало для Unix ... просто Solaris ... Mac OS X основана на Unix и имеет феноменальный пользовательский интерфейс, различие между двумя в том, что Sun действительно не заботится об интерфейсе так, как Apple). Они даже продают ТОНКИХ КЛИЕНТОВ, которые пытаются выдвинуть все на сервер.

Так что ... в любом случае ... Microsoft - это, в основном, компания-клиент, а Sun - это, в основном, серверная компания.

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

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

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

При действительно высоких требованиях к надежности проверка исключений МОЖЕТ быть полезной. Если есть сценарий, которого вы не ожидали, и для вашего бизнеса важно, чтобы вы все ожидали, то компилятор скажет вам ... «эй, вы не обрабатывали исключение RocketFuelExhaustedException».

Итак, я думаю, что проверенные исключения проистекают из точки зрения Sun как поставщика сервера.

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

Это все равно мои $ 0,02 ...

Answer 4

Основная причина в том, что дизайнеры C # решили не использовать «проверенные исключения». Это означает, что разработчик не должен заключать в себе блок обработки исключений внутри блока try-catch. Считалось, что это полезно только для небольших приложений и не приносит реальной пользы для больших проектов. Кроме того, проверенные исключения фактически использовались разработчиками, которые постоянно используют пустые блоки catch. Поскольку нет проверенных исключений, нет причины для объявления метода, какие исключения могут быть выброшены.

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

Answer 5

Исключениями являются, по-видимому, «исключительные» события. В парадигмах .net исключения не должны возникать (поэтому у вас есть методы, такие как TryParse, ...), поэтому нет смысла заставлять обрабатывать события, которые в любом случае не должны происходить.