- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
OutputStream stream = openOutputStream();
Throwable mainThrowable = null;
try {
// что-то делаем со stream
} catch (Throwable t) {
// сохраняем исключение
mainThrowable = t;
// и тут же выбрасываем его
throw t;
} finally {
if (mainThrowable == null) {
// основного исключения не было. Просто вызываем close()
stream.close();
}
else {
try {
stream.close();
} catch (Throwable unused) {
// игнорируем, так как есть основное исключение
// можно добавить лог исключения (по желанию)
}
}
}
Follow us!
В С++ с этим все в порядке. Если он выбросит исключение никакой код не поможет, программа упадет.
Может. Но самое западло в том, что эта тварь в некоторых случаях его не генерирует, а молча поедает... И хоть заобрабатывайся :(
http://govnokod.ru/14254
Деструктор ostream'а съедает ошибку из flush(). Прога думает, что файл успешно записан. Но на деле последние 5 байт не записались. Кровь-кишки-пиздец-котёнку.
Мораль: вызывайте close() явно, и если не включены exceptions(), то еще и проверяйте флаги на потоке после этого. Нельзя доверять закрытие файла RAII ;(
Т.е. как-то так:
не сделал flush() - ссзб
может, у тебя там неконсистентные данные - зачем они в файле?
Дык питушня как раз в том, что деструктор пытается сохранить эти данные в файл. "Ой, не получилось... Да и хуй с ними, все равно об ошибке уже никак не сообщить." Медвежья услуга... Если бы оно всегда не вываливало буфера - об этой фиче знало бы больше людей, и все бы писали явный flush()/close()...
А свое невежество признаю, ибо давно уже надо было догадаться о том, что flush() надо делать самому ;(
чёрд, там тоже гц
если интересно - см. полезные ссылки на вики На fpcomplete довольно доступно написано, хоть и букв много. В целом более общая и надёжная (в плане управления ресурсами) альтернатива вещам вроде getContents. Пробовал разок их использовать для потоковой обработки и конвертации больших xml-файлов, всё работало, но моск выносило.
Ради новых идей, ради фана, чтобы мозг не отупел от ебучего энтерпрайза... ;)
Имхо, как отдельный интерпретатор, в котором предлагается писать внешние интерфейсы (гуй или сервер) на прологе (как это сделано в визуал прологе) он нахер не сдался.
А вот как встраиваемый модуль или как клиент-серверную СУБД пролог поюзать было бы интересно. В таком исполнении на прологе будет только то, для чего он предназначен. А остальное возьмут на себя обычные языки.
интырпрайз не заинтересован в непопулярных технологиях, т.как они делают производство более дорогим.
У того и у другого есть реализации привязаные к базам данных, но... их еще нужно допиливать / они не в тех базах, что нужно. Пролог есть в АллегроБД (но это Пролог с очень большой натяжкой, на самом деле - КИФ + добавлено несколько функций из Пролога), Паверлум кажется с Постгрес работает, но... а как же индекс-фри аджасенси. Вобщем, платформа не та.
Есть еще ризонеры, рул-бейсд-сыстемс навроде Гандальфа, Джесса и т.д. Но это все не интырпрайз а маргиналы.
Тру интырпрайз использует Стандартные инструменты работающие с только со стандартным ХМЛем, например айлог (веб-сфера).
Его даже стандартизировать хотели, но что-то у них не срослось.
Тут как бы ситуация такая: сам по себе язык может быть интересным, но без возможности применить его к настоящим данным, он утрачивает всякую практическую ценность. Т.е. нужно смотреть, есть ли какой-то способ работать с базами данных и с какими. Ну и есть ли вменяемый тулчейн, начинающийся с импорта онтологии в каком-нибудь РДФ / КИФ в базу данных, с последующей интерпретацией этих данных.
Реляционные базы данных не фонтан для этих языков, потому что все такого рода системы построены на алгоритмах обходящих графы. Т.е. хорошими БД для них были бы либо что-то типа Беркли, либо графовые БД. Ну и дальше в зависимости от алгоритмов, которыми пользуется язык, может быть что хранилище триплетов лучше, а может проперти-граф лучше.
Язык может быть сам по себе быстрым, но первая же проблема с которой прийдется столкнуться на практике - вся онтология не влезет в доступную память, и нужно будет работать с БД, и там уже скорости будут зависеть от других факторов.
Вот, есть еще новинка эмо-куб :) Если публике понравятся, и у него появятся клоны, то вполне возможно у отрасли появится финансирование, для нее напишут эсдикеи, ЛАМП и задеплоят на годадди. Но пока, похоже, что ничего особо интересного не происходит. Экспертные системы, как оказалось, очень тяжело сделать хорошо, и массово их делать в обозримом будущем не получится (Ватсона вроде пытаются научить медицине, но даже при том, что вроде успешно, на конвеер такие разработки пока не поставить).
> и массово их делать в обозримом будущем не получится
Почему?
И кстати что-за эмоклуб?
А вообще проблематика кажется неподъемной для человека за его короткую жизнь.
It's Beemo!!!
Ну ок, не Бимо, но может быть когда-нибудь:
http://emospark.com/
Экспертные системы требуют:
1. Недюжей квалификации от програмистов (у меня недостаточно, например, в институтах этому не учат, вообще не понятно откуда брать специалистов).
2. Более того, экспертные системы нужно учить используя настоящих (живых) экспертов. Это значит, что для разработки одной штуки систем, нужно в течение нескольких лет обучить человека-эксперта заполнять данными систему, проверять ее на правильность, кормить с чайной ложечки и т.д. Нужно чтобы человек-эксперт имел не только общее представление, но и какой-то опыт заполнения такой системы, чтобы у него появилась интуиция помогающая понять как заданые правила повлияют на принятые решения. Большинству людей не хватает дисциплины ясно выражать свои мысли, т.е. в такой степени, чтобы это было просто записать в виде правил такой системы.
Фейл экспертных систем в прошлом восновном был именно изза людей-экспертов, которые просто не справились с этим покемоном. Ну это на какое-то время подтолкнуло к разработкам в области искусственных естесственных языков, с целью научить людей-экспертов лучше выражать свои мысли, но мода прошла, а результатов почти никаких не оставила.
В принципе, человек же примерно также учится.
Если человека учить только снизу вверх - то испертом он и к концу жизни не успеет стать ;)
Все-таки человек во время обучения пользуется туевой хучей данных, которые обработали и сформулировали до него...
Заодно из-за этого базис мышления получается более-менее общим, и люди могут делиться знаниями друг с другом. Если же каждый будет учиться с нуля - скорее всего он ничего не сможет передать другому, т.к. его банально не поймут.
Да, существовало и существует мнение, что человек как-то так учится, но оно не подтверждается практическими наблюдениями. Если бы человек так учился, то для того, чтобы научиться читать, нам бы нужно было осилить что-то вроде Ворднета, несколько сот раз (нам бы просто жизни не хватило это сделать). Есть и другие проблемы. Например, современные парсеры текста построенные на статистическом обучении, в состоянии "понять" около 85% от прочитаного (человек - примерно 95%). И хотя это очень близко, нет вообще никаких идей по поводу того, как добиться такого же процента, как и у живых людей. Даже если бы мы могли скормить статистическим машинам всю доступную информацию, на всех языках, это бы ничего существенно не улучшило.
Мое предвзятое мнение - люди в огромной степени учатся не из опыта, а просто запоминая то, что делали другие. При этом, понимание совсем не обязательно. Очень большой процент понимания у людей можно описать экспериментом Гетиера, это когда человек приходит к правильному выводу руководствуясь неправильными посылками.
Но тут возникает другой вопрос: а нужна ли нам система, работающая по такому принцыпу? Мы же вобщем-то согласны пожертвовать временем и энергией для того, чтобы получить гарантировано правильный результат. А человеческое мышление, похоже, заточено на скорость, а не на правильность...
Пока люди не научатся решать все задачи хотябы за линейное время, всегда будет потребность решать не точно, но быстро.
Ну и многих интересных задач просто не существует гарантированно правильных результатов. Иногда эти результаты вообще непонятно как строго сравнить. Примеры: поиск, системы рекомендаций и т.п.
Работу антиспамов можно точно оценить, но нестатистическими методами эта задача практически не решается.
> люди в огромной степени учатся не из опыта, а просто запоминая то, что делали другие
Ну так это как раз про статистические методы: просматриваем готовые решения, в похожих ситуациях принимаем похожие.
По поводу результатов: речь о другом. Одно дело, когда мы можем гарантировать размер ошибки в каких-то пределах, а другое дело, когда мы можем гарантировать, что ошибка случится только в каком-то проценте случаев, но размер ошибки может быть какой угодно. Алгоритмы второго типа имеют очень мало областей применения (хотя их и пишут очень часто...)
я утверждаю, что само понятие размера ошибки иногда сложно определить.
Каков размер ошибки в выдаче гугла? В саджесте "читавшие X также выбирают Y"? В предложенной корректировке спеллчекера?
Антиспам-фильтр пропистил письмо в одном случае из миллиона. Каков размер его единичной ошибки?
Так вот в этих же терминах можно добиться того, чтобы поиск находил значения не дальше какого-то значения от целевого, а можно добиться чтобы он иногда находил целевое значение, а иногда - нет. И это очень разные вещи. В переносе, например, на РТС: в первом случае юнит пойдет воевать с игроком, но может не всегда будет стрелять точно по юнитам противника, а во втором случае юнит может пойдет воевать, а может пойдет лес рубить...
Которая внезапно скорее всего будет основана не только на расстоянии левенштейна, но и на вероятности произвести ошибку заданного типа, вероятностях перепутать конкретные буквы и т.п. вещи, полученные из статистического анализа ошибок, типично совершаемых людьми. Если у нас внезапно не среднестатистические люди с другой раскладкой, то ваша эвристическая функция для них вообще ни разу не мерило истины.
A conduit, in esoterism, and spiritual discourse, is a specific object, person, location, or process (such as engaging in a séance or entering a trance) which allows a person to connect or communicate with a spiritual realm, metaphysical energy, or spiritual entity, or vice versa. The use of such a conduit may be entirely metaphoric or symbolic, or it may be earnestly believed to be functional.
In Shinto, the public shrine is a building or place that functions as a conduit for kami (神 "spiritual essence"?, commonly translated as god or spirit). In Yoruba culture, it is said that Elegba, the son of Osun, became the great conduit of ase (divine energy) in the Universe.
Чуть было не пропустил!
> translated
Вроде о компиляторах ;)
Монады — это живые, духообразные единицы, из которых все состоит и кроме которых ничего в мире нет.
Есть одна из многих алтернативная реализация кондуитов с более говорящим названием Pipes.
"Смеюсь вельми гласно"
на деле же - ты что-то пишешь в ostream (fstream), который внутри полиморфно использует streambuf (filebuf)
благодаря полиморфизму ты можешь управлять буферизацией, поведением по сбросу буфера на устройство и т.д.
именно поэтому есть метод flush() у потока, который делает сброс, вызывая метод flush() у своего буфера
хочешь, напиши свой класс файлбуф да скорми потоку, в нем делай сброс хоть посимвольно - да пожалуйста
а то, что обычно тебе flush не приходится вызывать вручную, так это только потому, что при записи текста \n имеет тот же эффект
равно как и нормальное закрытие файла тоже сделает flush()
а при исключениях - ну что то там у тебя недосбросилось в файл, так может, это и к лучшему?
Самое грустное, что не особо понятно, что делать, если во время раскрутки стека не удалось освободить ресурс...
А это как раз из-за того, что в этих случаях смешивается commit и release.
Само по себе освобождение ресурса не может завершиться неудачей. Даже если это был сетевой ресурс.
не спешите, сударь
Допустим, у нас есть файл лога транзакции и поднятая распределённая транзакция. Запись в файл кинула исключение, нужно и файл закрыть, и транзакцию корректно завершить (что также может не удастся: сеть у нас упала).
Понятно, что это можно корректно реализовать. Только реализация превращается в адовое месиво трай-кетчей (особенно для типичного числа занятых ресурсов), для избавления от которого и придумали RAII.
Вопрос в том, можно ли это сделать меньшей кровью...
Самое грустное, что это вообще нигде не особо понятно.
я именно это и имел в виду.
Юзать его дальше один хрен уже нельзя. Остается или записать в лог и забить, или вообще с горя сделать abort(). Вменяемой обработки тут не придумать.
Да почему. В крестах убивают прогу за исключение, вылетевшее из деструктора, который был вызван из кода размотки стека, вызванного другим исключением. Если его успели поймать до этого, и деструктор нормально вернул управление unwinder'у - все будет норм. Т.е. если в деструкторе написали try { close(); } catch (...) { // ignore this shit }, то оно молча съест второе исключение и не упадет.
Короче сложная штука жизнь.
Только в успешной ветке.
Получается, что при успехе надо делать close() самому, чтобы не проебать ошибку о закончившемся месте на фс. А при любом фейле можно доверить закрытие деструктору, который тупо сожрет эту ошибку - нам уже похрен, мы и так знаем, что файл запорот.
P.S. Во всем виноваты ленивые пидорасы, совместившие commit и release в одну функцию close(). А теперь все на всех платформах и языках за это расплачиваются...
Что перезатрётся? Какую проблему решает этот код? Для кого supressed exception сделали?
Проблему нежелающих слезать с Java 6
Chained-исключения превратили исключение в список, а подавленные исключения превращают обход всех исключений в дерево - вот в этом ключе можно было вбрасывать.
Другое дело - C#, емнип там до сих пор такого нету - using, как и try-finally глушит исключение, плюс баг инициализаторов в ихнем using.
Правда тут уже обсуждали и supressed, и C#.
В C# до сих пор не пофиксили это
http://ideone.com/uVjmf4
finally выполняется последним, соответственно, его обработка стоит выше вылетевшего кода.
Поэтому в Dispose паттерне и написано избегать исключений (Кроме ObjectDisposedException) во время освобождения ресурсов:
http://msdn.microsoft.com/en-us/library/b1yfkh5e%28v=vs.110%29.aspx
Тем более в C# же нет механизмов для контроля невозможности выброса методом исключений.
Как-то так:
Тем более в C# же нет механизмов для контроля невозможности выброса методом исключений.
В шарпике я так перекрываю выброс исключения так:
В жабе я видел мудрёные конструкции, но т.к. жабу всё так лизать не собрался, вариантов не знаю. :)
Понимаешь, в мире существует жидомасонский заговор, состоящий в том, что миллионам неофитов впаривают, как пиздато жить со сборщиком мусора, ооп (итак дети, какие три слова надо вызубрить наизусть, когда говорим об ооп? правильно) и исключениями. Миллионам неофитов впаривают дерьмо, как хуёво живётся за пределами этого мирка и что там памятью управляют только руками. Когда неофитов якобы учат крестам, то их учат только сишке с новым словом class. В результате про РАИИ никто нихуя не знает. Никто не знает, что такое вообще есть. Постулат один - есть ужасные нативные языки, в которых есть ужасное ручное управление и постоянные порчи памяти. Все пользуются этим дерьмовым ГЦ, с ручным закрытием ресурсов и считают, что они пиздато живут.
На самом деле таки да, РАИИ требует IQ больше 100, количество пионеров-крестоблядей, считающий, что они умнее компилятора, и ищущих утечки одинокими долгими вечерами, подтверждает это. А в жабу обезьянок нанимать дешевле, чтоб сидели и прыгали по клавиатуре, и прыгали!
Ну и в крестах close() все-таки не пожирает ошибки от flush()'а.
А РАИИ меня ещё с Ады вставляло.
Мне сегодня снился жилой дом, построенный внутри гаража.