Значит, ни о какой востребованности не может идти речи. Вот на C# куча вакансий, есть и ASP.NET (в основном), и GUI на WPF, и мобилки, и геймдев с Unity.
Обычно дальше работать уже нельзя, так как по сломанной ссылке лежит что-то важно или свалились во время какого-то сложного процесса и в таком месте где восстановиться уже нельзя.
Зависит от приложения. Если это какой-нибудь научный расчёт — согласен. Если это система обработки более-менее независимых друг от друга запросов, чаще всего просто возвращается ответ со статусом «Ошибка сервера». При этом само приложение продолжает работать и обрабатывать другие запросы.
Чтобы это работало надо изначально продумывать все места где может упасть исключение и понимать как восстанавливаться после поломки, в 99% этого не сделано потому что об этом либо не думали, либо не ожидали, либо обработка и восстановление слишком сложное и дорогое по реализации.
Как раз таки исключения обычно делают достаточно безопасной работу после ошибки. Это в каком-нибудь C можно бояться — а проверят ли код возврата наверху? А может лучше молча сделать abort(), чем рисковать тем, что не проверят. В Java нужны специальные усилия, чтобы погасить исключение. Обычно оно нормально улетает наверх, где есть код, который может его поймать и предпринять какие то действия. Всякие файловые дескрипторы будут нормально закрыты, память будет нормально освобождена, транзакции будут нормально откачены. Да, может остаться какой-нибудь временный файл неудалённым, но это не очень страшно.
Смотря какие у тебя задачи. Почти для любой задачи можно найти более подходящий язык. Но в то же время почти для любой задачи Java будет достаточно хорошим выбором.
Имхо, если ты не старпер и действительно энтузиаст ЯП, то на такие заковыристые вопросы с удовольствием поищешь ответы, просто j4f. Но я не про тебя лично.
Если это система обработки более-менее независимых друг от друга запросов
То есть будет работать в простейших случаях. Например, из последнего, в той же apache kafka мы ловили None.get (это аналог обращения к null в scala), который приводил к остановке тредов-обработчиков сети. Да, приложение работает, но уже не может обслуживать клиентов. Почему оно возникает не знают даже разрабы кафки (тикет в jira, естественно, завели), как восстанавливаться, тоже х.з., так как там довольно нетривиальный код инициализации структур, поэтому просто обложили try/catch/Runtime.halt и стало всё зашибись — если возникнет, то упадет, переподнимется, опять будет обслуживать клиентов.
Всякие файловые дескрипторы будут нормально закрыты, память будет нормально освобождена, транзакции будут нормально откачены.
В идеальном мире так и будет, а в реальности потекут и дескрипторы и объекты и транзакции, если нет обработчиков в блоке finally.
То есть будет работать в простейших случаях. Например, из последнего, в той же apache kafka мы ловили None.get (это аналог обращения к null в scala), который приводил к остановке тредов-обработчиков сети. Да, приложение работает, но уже не может обслуживать клиентов. Почему оно возникает не знают даже разрабы кафки (тикет в jira, естественно, завели), как восстанавливаться, тоже х.з., так как там довольно нетривиальный код инициализации структур, поэтому просто обложили try/catch/Runtime.halt и стало всё зашибись — если возникнет, то упадет, переподнимется, опять будет обслуживать клиентов.
Ты распространяешь сложный случай на все случаи. В вашем случае видимо проще стопать. Но это знак того, что код написан не очень хорошо, а не того, что NPE каким то образом плохо влияет на работу приложения. Он по сути ничем не отличается от, например, NumberFormatException. Пользователь ввёл вместо числа букву — будем падать?
Мой поинт в том, что JRE никак не зависит от NPE. Вылетело — JRE продолжает работу в штатном режиме. То, что логика конкретного кода ломается при неожиданном исключении, это другой вопрос. JRE программу за программиста не напишет. Странно ей предъявлять какие-либо претензии.
Этим Java отличается, например, от C. Хотя конкретно разыменование null-а в C, наверное, тоже вполне безопасно, но можем ли мы этот факт узнать в обработчике сигнала? А если там было разыменовано что-то другое, тут уже точно лучше упасть. Кто его знает, что там происходит. Раскрутить стек мы не можем.
В идеальном мире так и будет, а в реальности потекут и дескрипторы и объекты и транзакции, если нет обработчиков в блоке finally.
Ну если дескрипторы обрабатываются не через finally, это просто плохо написанный код. В таком коде всё будет течь и так, могу по опыту сказать. Сталкивался, к сожалению. Проще в полночь всё перезапускать. Всё же идиоматичный код на Java обрабатывает ресурсы через finally (try-with-resources в Java 7+). То же с транзакциями.
Ну если дескрипторы обрабатываются не через finally, это просто плохо написанный код.
Не обязательно. Это может быть асинхронный код, где освобождение ресурсов должно идти в другом месте. Типичный пример: код с использованием библиотеки akka. В случае с C++ нас спасают shared_ptr и деструкторы, а в случае с java надо обвешиваться счетчиками/метриками и мониторить каждый чих программы, иначе потом концов не найдешь.
Это идиотизм. Легионер все правильно сказал, нужно только понять, что все эти преимущества заключаются в одном (!) языке, а не «си умеет N, руби умеет M, а жаба нинужна».
Есть еще один язык, программы на котором работают вообще на всем, от восьмибитного контроллера в пылесосе (с сотней байт памяти), до суперкомпьютеров, для которых он является основным языком написания операционной системы. И этот язык в обоих своих ипостасьях язык тоже вроде бы один и тот же.