mayton,

Ну, в Ada и pl/sql тоже нет следов "checked exceptions" и воркинк джаст файн - никто не жалуется.
У Эккеля в этом абзаце существенно важнее предложения этот абзац начинающие, а не заканчивающие.
http://www.mindview.net/Etc/Discussions/CheckedExceptions [/]Нужны ли Яве контролируемые исключения
Нужны ли Яве контролируемые исключенияChecked exceptions seem like a really good idea at first. But it's all based on our unchallenged assumption that static type checking detects your problems and is always best. Java is the first language (that I know of) that uses checked exceptions and is thus the first experiment. However, the kind of code you must write around these things and the common phenomenon of "swallowed" exceptions begins to suggest there's a problem.

Это не просто "первый эксперимент", а такой "первый эксперимент", который больше никем не был повторен.
То есть ошибка (одна из) проектировщиков языка.

Касательно Go - существо дела здесь видится не в том, что GO хочет вернуть программиста во времена возврата кодов ошибок в C,
с немедленными проверками результата по вызову функции, а в том, что предоставляет программисту первоклассный тип, определенный в базовом синтаксисе языка ( т.е. - часть внутренней общеязыковой библиотеки), позволяющий протягивать иформацию об ошибке сквозь набор вложенных функциональных вызовов.
Т.е. - шаблон проектирования а-ля "старый добрый С" может быть реализован с разбегу.
Но проектировщики GO закладываются и пропагандируют "функциональный" подход к проектированию программ и обработке ошибок в них:
они мягко предлагают разработчику код, внутри которого может происходить ошибка, формулировать в виде самостоятельной лямбды,
возвращая информацию о ней в виде известного компилятору навсегда единого типа данных.
И обрабатывать эту информацию в отдельном блоке кода по завершению вызова той лямбды.

Это 100% тот самый подход, который сейчас проникает в Java через форточку, открытую в 8-ке путем вживления а-ля лябд (синтаксически - так именно лямбд).
Только в Java всю эту механику (пока?) нужно реализовать своими ручками, объявив подходящие клиентские классы для проброса информации об ошибке из лямбды в вызывающий код.


PS
про checked exceptions в Java - с одной стороны, мне еще продолжает казаться что они из Java будут выведены
только вместе с выносом самой Java из массовой практики кодирования.
С другой стороны, глядя на то, какой кинжал сейчас всобачивается в сердце унаследованного Java-кода путем заявления к выходу
"модульной" Java-9, я уже готов поверить, что к выходу какой-нибудь Java-13 будет сказано - забудьте про checked exceptions - больше этот синтаксис мы не поддерживаем.

mayton,
тебе будет интересно:
вот интервью 2003 года,
http://www.artima.com/intv/handcuffs.html

при несколько вольном пересказе получится так:
Брюс Эккель спрашивает а Андерса Хейлсберга
- как же это вам удалось не вляпаться в checked exception при проектировании С#? - ведь "зашибись-идея" - тогда так все думали.
- Ну, правда - мы искренне считали это "зашибись-идеей". Тогда что-то удержало, а теперь я всем рассказываю, что не верю в масштабируемость кода, построенного на таком синтаксисе.


Эккель не просто троллит Хейлсберга, а троллит, обладая точным знанием, что до создания C# Хейлсберг занимался в Microsoft
реализацией J++. Т.е. в смысле бытовой психологии у него практически не было шансов не перетащить "клевую фишку" в новый язык.

mayton...Надеюсь что это не будет представлять археологический интерес.

Это тебе решать...
хочу вот на что предложить обратить внимание
- работа взаимодействующих компонентов, в общем случае - в разных процессах (явно упоминается в интервью).
- работа "твоего" кода из-под неуправляемого тобой хост-приложения, когда необработанная ошибка в твоем коде может приводить к аборту всего хоста.
В обоих случаях не типизированный до checked (уровня compile-time) try-catch - это доктор, который в одном catch спрашивает у
полученного объекта ошибки (runtime) - родной, так что же в том вызове не так приключилось?

Т.е., с точки зрения вызывающего ошибка, - это возможная, ожидаемая часть данных , приезжающая из вызова.

"Красота" compile-time checked захода, явленная в виде ветвистого наследования типов ожидаемых ошибок не только обязывает вызывающего знать их все наперечет (только для того, чтобы скопипасть нужное количество раз вывод текста сорта "оно там не смогло сработать, и я об этом знаю в своей собственной, отдельной для этой конкретной разновидности не срабатывания ветке кода "), но и обязывает передавать такого рода знание дальше по стеку вызова, если внутри текущего блока не находится разумного способа обойтись с обнаруженной проблемой, навязывая вышележащим слоям из ниоткуда появившуюся необходимостью иметь информацию времени компиляции об устройстве нижележащих слоев.
Это особенно радует с учетом того обстоятельства, что compile-time информация о вызываемом может быть подставой чистой воды.
Что за радость получить скомпилированный код и крашнутое приложение, вместо возможности обработать runtime-error без краха вызывающего?

Разработчики Go/Golang всего лишь сказали следующее: ну и нафига нам вообще вся эта лабуда, включая unchecked, в конце концов.
Если информация об ошибке - часть данных , приезжающая из вызова, не проще ли информацию об ошибке явно инкорпорировать в состав возврата, получаемого из вызываемого кода.

Выбросим-ка мы все это добро разом, вместе с обсуждением о "состоянии" системы в момент вхождения в блок catch,
напоминаниями разработчику о том, что не есть хорошая идея использовать try-catch для управления бизнес-кодом (а нескромный вопрос - зачем тогда вообще придумывать управляющие конструкции - неужели только для того, чтобы писателю книжек всегда было обеспечено несколько страниц, на которых он тщательно объяснит, почему ими не надо пользоваться?).

Для управления кодом есть ясный и понятный if.
А вот в куда этот if должен двигаться - имеет право определяться приехавшими из вызова данными.


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

[quot Alexey Tomin]booby ...

Но тут я не согласен- checked exception это хорошая абстракция, годная.

Об этом лучше не мне рассказывать ( я на java не программирую), а сразу (на выбор) Блоху, Эккелю или Гетсу. Тем более, что каждый из них обладает ясным представлением мотивации, приведшей к стандартизации этой штуки в синтаксисе языка.

Мое же имхо, состоит в том, что в системах программирования с использованием подсистем управления исключениями с 1980 года ничего не произошло в том смысле, в каком тогда Хоар хотел их "почистить".
Тогда - применительно к Ada как кандидату на безопасный язык.
Всего-то и оставалось, что привести в порядок exception handling до степени, достойной "безопасного языка" и можно, не боясь, Ada в каждый танк засовывать.
А без этого ракеты до Венеры не будут долетать, а в городах начнут самопроизвольно взрываться атомные бомбы.

Как тогда, так и сейчас наличные подсистемы не могли гарантировать декларативным образом (т.е. нельзя было написать гарантирующий это компилятор), что полученная программа
- не испытает краха из-за отсутствия обработчика верхнего уровня
- полученная ошибка будет обработана в "правильном месте" и "правильным образом"
-

Попытка Java в этом смысле навязать разработчику обязанность разбираться с тем, что проектировщики ( кхм... а тут уже не языка, а библиотечной части, что является совершенно отдельной частью Марлезонского балета) посчитали необходимым обязать его разбираться, хоть и бравая, но сама по себе не может служить и не является гарантией вообще ничего, кроме 100% резервированного места под try-catch.

Исключения вносят в код семантику косвенного управления. Разрывая "естественные" границы единиц кода.
Превращая семантику вычисления в необозримую.
Попытка проверяемых исключений локализовать обязанность по обработке таких исключений не меняет существа дела как потому, что допускает возможность их пере-испускания на верхний уровень, так и потому что обычные, не проверяемые, исключения при этом не перестают существовать.
Даже там, где требование компилятора сработало и ошибка оказалась обработанной в месте своего возможного появления, у компилятора нет никаких ресурсов установить, что обработана она была правильно с точки зрения заявителя такой ошибки - открытый файл окажется закрытым и бомба самопроизвольно не взорвется.
Иначе не было бы никакой нужды спустя 20 лет от реализации такой зашибись-возможности вживлять в язык try-with-resources

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

mayton... или надёжность была ВСЕГДА а протокол это просто РИТУАЛ
который мы каждый день исполняем просто так... потому что Гослинг и иже с ними так решили.
Все наоборот.
Любая система построенная на пробросе и "управлении обработкой" исключений - с гарантией ненадежна .
И сам Гослинг никогда не был и не есть "глупый человек". Ну, может быть, он всего лишь "недостаточно гениальный".

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

Сейчас не могу привести ссылку, но где-то но где-то Хоар высказывался в таком духе, что что в смысле надежности языка на первом месте стоит даже не проблема обработки ошибок, а, куда более простая, проблема не инициализированных переменных.
Так вот Хоар винил лично себя (не Вирта), говоря о том, что лично совершил многомиллиардную ошибку (стоившей все отрасли много миллиардов потерь из-за автоматического непрерывного воспроизведения в языках-последователях),
разрешив в ALGOL W сравнения указателей с null. "Безопасная" Java прошла мимо сего обстоятельства, даже не заметив его.

Basil A. Sidorovbooby Любая система построенная на пробросе и "управлении обработкой" исключений - с гарантией ненадежна Вас кто-то обманул, т.к. механизм исключений не является гарантом надёжности чего-бы то ни было.
такая формулировка тоже годится, даже если кто-то меня обманул.
:)