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 Любая система построенная на пробросе и "управлении обработкой" исключений - с гарантией ненадежна Вас кто-то обманул, т.к. механизм исключений не является гарантом надёжности чего-бы то ни было.
такая формулировка тоже годится, даже если кто-то меня обманул.
:)

Petro123maytonили парадигма кодинга продолжает использоваться и в настоящее время.
это только для узких случаев:
- стека практически нет. Один уровень в main

стек здесь возникает на каждом вызове библиотечной процедуры.

Petro123- БЛ нет и управлять исключительными ситуациями не надо. Весь код не делает ничего интересного кроме выплёвывания ошибок в выходной поток.

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

Petro123- т.к. высокая производительность, то в жертву принесено всё остальное удобство от ООП до try и т.д. т.п.

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


Petro123ЗЫ
Прикладной код с поведением пишется совсем по другому.
У данного кода только 2 состояния - ВКЛ\ВЫКЛ
Такое вполне можно применять напр. при сериализации. Будет 2 состояния: Поучилось и НЕполучилось.

Вы ошибаетесь. В смысле выходного состояния у этой функции одно состояние. Всегда ВКЛ. Все получилось.
Могло бы быть и два и больше - прямо по тексту вычитывается как минимум пять разумных состояний возврата,
но автор кода решил обойтись одним.
Принципиально в контексте обсуждения именно checked exceptions не вопрос о том - является ли здесь выдача единственного результата ошибкой программирования (имхо - является, но не это критично важно для безопасного программирования),
а вопрос о том, не разрушается ли весь локальный мир всего того адресного пространства в котором запускается этот код при неудачном вызове.
И ближайшим кандидатом на разрушение мира в этом коде является фрагмент


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

Вероятно, рассматривание кода примерно такого сорта сорта и должно наводить на желание вписать прямо в контракт функции socket
обязанность по обработке контролируемого исключения.
Но ровно этот же код и показывает пример того, насколько бесплодна затея,
если программист поставил себе твердую цель потушить полученную информацию методом недеяния, игнорирования результата.
(Зачем-то для чьих-то досужих глаз записывая некий мусор в лог.
Конечно, когда система полностью встанет от полной блокировки ресурсов - появится заинтересованный читатель полученных логов с приветами от программиста.
А вот у этого заинтересованного читателя ответить письменным образом "в лог программисту" может не оказаться возможности.)

mayton..
Можно предположить что механизм try-catch можно считать производительным когда у нас
есть соотношение к примеру 95% : 5% в чести успехов/неуспехов в блоке try
...

ну, в пару кликов можно найти утверждения (касающиеся, возможно, устаревших версий java), что генерация/обработка исключений
может быть примерно в 200 раз дороже кода, полностью лишенного исключений.
т.е твое соотношение должно быть 99.95%:0.05%
на сайте Михаила Воронцова любопытный разбор методов кодирования/декодирования в/из Base64
Самыми медленными - от 3.5 до 50 раз в зависимости от размера кодируемого по отношению к ближайшим конкурентам оказываются
самые секретные sun.misc.BASE64Encoder и sun.misc.BASE64Decoder (ну, и самые древние).

По единственной причине - оба используют механизм исключений как элемент своей управляющей логики.
http://java-performance.info/base64-encoding-and-decoding-performance/


У него же есть обзор - на что в комбинации try - throw new CustomException("Horror!") - catch уходит время.
То, что try в любой системе с исключениями почти или полностью бесплатен - легко ожидать.
У catch самого по себе тоже нет оценки времени. Все время так или иначе уйдет на механику получения точки catch, переход на нее и передачу информации о самой отлавливаемой ошибке. Т.е. В любой системе время будет концентрироваться вокруг
throw new CustomException("Horror!")

На основании своих замеров Михаил утверждает, что сам по себе throw тоже практически несущественен.
Все время целиком уходит на new CustomException("Horror!").
При этом, если подавить механику формирования трейс-стека при конструировании объекта - ситуация улучшается в 10 раз,
а если отказаться от new (или даже вообще от extends Exception для формирования объекта, несущего информацию об ошибке),
то еще в 10 - 30 раз по отношению к предыдущему 10-кратному улучшению.
Т.е. в Java создание объекта исключения для переноса простой информации - чистопородное эстетство.
http://java-performance.info/throwing-an-exception-in-java-is-very-slow/

mayton,

сравнивал - они у него и есть рекомендуемые для тех кто хочет стандартных решений, ну или на втором месте после
javax.xml.bind.DatatypeConverter - это для гиков и тех, у кого еще нет 8-ки.

maytonЕсли честно я всегда испытывал дискомфорт от отказа компиллятора собирать try{...}catch(){}

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

maytonкогда комментаришь какой-то пустяк и вдруг понимаешь что надо комментарить
всю секцию catch() а поскольку она - единственная - то надо убирать и try.

на первый взгляд - не вполне ясно - о чем печаль. Твоя рука - владыка.
Ты владелец внутренней структуры своей программы.

mayton....

И вобщем-то когда я комментарю строку я логически предполагаю что мое действие
которое я УБРАЛ не должно вызывать side-effects. А оно вызывает ибо контракт
предполагает ОБЯЗАТЕЛЬНОЕ протокольное декларирование IO-эффекта.

Вот такая досада.

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

Печаль здесь возникает от того, что там где никому, кроме себя, не должен - во внутренностях компонента, исключение
исчезнувшего checked-exception из контракта метода вызывает нелокальные изменения в исходном коде потенциально обширного компонента.
Оно конечно, ООП без SOLID (написанное пером - не вырубишь топором) не жилец.
Но не до такой же степени, что аж полиморфизмом этого нельзя поправить.

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

То есть они есть , но ты в своих контактах никогда их не используй.

booby,

контактах = контрактах