Почему NullPointerException является исключением на этапе выполнения и RemoteException нет?

Я не буду обсуждать решение, я просто процитирую объяснение решения от Энн Уоллрат (которая руководила проектированием и реализацией Java RMI). Это извлечено из этого сообщения из архивов RMI-USERS (сообщение от января 1999 г.):

Решение сделать RemoteException проверенное исключение и требует удаленного методы для перечисления исключения в его Пункт о бросках не является религиозным. Решение основано на том, как сделать надежные распределенные вычисления. Этот вопрос возникает каждый раз в пока в нашем списке пользователей. у меня есть подробный ответ, который я опубликовал какое-то время назад. Вот, если ты интересно. Я не мог найти это в rmi-users архив, поэтому я его включил ниже.

Ура,

- Энн

---

Я хотел бы обсудить обоснование сделать RemoteException проверенным Исключение, а не RuntimeException.

1) сети ненадежны

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

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

2) Ошибка RPC не может быть скрыта от клиент

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

3) отмеченные исключения способствуют большему надежные программы

Было время, когда Дуб и в самой ранней версии Java не было проверил исключения. Обработка исключений был рекомендательным, и это было небезопасно мир там. Это была наша группа (Джим В частности, Уолдо и я :-), что рекомендуется делать исключения проверено компилятором.Джим был довольно убедительно в своих аргументах, рассказывая мира, где надежный код царствовать. После некоторого размышления Java был переоборудован, чтобы проверить исключения. Только те исключения для Которые не было восстановления или отражения ошибки приложения не будут отмечены (например, OutOfMemoryError, NullPointerException соответственно). И мир снова стал безопасным.

Представьте себе удивление инженеров Java когда много исключений в Java API и компилятор были изменены с unchecked to проверено, а компилятор усилили различие, они обнаружил ошибки в реализациях! Итак, все усилия по обработке ошибки условия, какими бы благими намерениями они ни были, было недостаточно хорошо. Этот компилятор полезно для чего-то: -)

4) RemoteException должно быть проверено исключение

Хорошо, так что вернемся к делу. Поскольку RemoteException - это факт жизни в Вызов RPC (см. # 1, # 2) и проверено исключения заставляют вас писать безопасно код (# 3), мы думали, что RemoteException проверенное исключение была хорошая идея. Написание надежных распределенные программы достаточно сложны, без компилятора, чтобы помочь вы за исключением.

Итак, некоторые могут возразить, что RemoteException похож на OutOfMemoryError; ваша программа должна упасть замертво, если удаленный вызов не удастся. Я не согласен с этим. Да, в в некоторых случаях нет восстановления от RemoteException; но если ты написание надежного распределенного программа, ваш клиент должен уловить отказов и повторите попытку. Возможно, вам нужно связаться с другим сервер или прервать транзакцию некоторых Сортировать.Если RemoteException не обработанный, он будет просачиваться и сбой вашего клиента (юк).

Другие утверждали, что есть некоторые удаленные интерфейсы, которые используются в как локальный корпус, так и удаленный случай, и клиент не должен иметь дело с исключениями в местных случае, поэтому RemoteException не должно должны быть в пункте о бросках и обращение с ним не должно быть обязательным. Теперь, если мы разрешили удаленный интерфейс методы для исключения RemoteException и был переключатель "rmic" для создания заглушек это вызовет непроверенный RemoteException, клиент имеет нет выбор в этом вопросе. Решение обработка исключений должна оставаться с клиент. Если вы определяете интерфейс что выдает только непроверенные исключения вы никогда не сможете написать клиенту, который требуется помощь компилятора в работе с эти исключения. Мы уже из приведенного выше примера видно, что проверенные исключения способствуют надежному код.

Еще одна проблема, которая возникла сейчас и опять же, разработчикам необходимо просто перевести локальные интерфейсы и использовать их как удаленные интерфейсы. Этот может работать для небольшого набора случаев, но если интерфейс не был разработан с параллелизм и частичный сбой и с учетом задержки вызова, протокол захваченный интерфейсом не может быть подходит для использования в распределенных кейс. Достаточно ли информации передано эти операции, чтобы сделать идемпотентные операции? Возможно, но скорее всего нет.

Помещение RemoteException в каждое бросает пункт может показаться болью, но это цена, которую нужно заплатить за письмо надежные распределенные приложения.

- Энн Воллрат