Свежие комментарии

Ой, вот про разные компиляторы я вообще не копенгаген. Попробую спросить у кого-нибудь.

Насчет контракта, немного смущает вот что: пользователю навязывается, что для информирования об ошибке он должен кинуть исключение, а вот в ответ ему потом придет errorCode. Если это какие-то сетевые ошибки, то как он получит о них информацию? Хотя бы в виде строчки. Я поэтому и предлагал запретить исключения, раз уж все равно сведения теряются.

Тем более, если стремно полагаться на бинарную совместимость. Вот если layout объекта фиксирован, как в .NET, то ради бога. А вот например в COM фиксирован только layout интерфейса, поэтому исключения наружу не летают, ошибки передаются через глобальный объект IErrorInfo (затычка, как errno).

1) Вывести на свой личный карточный счет ты можешь вообще все (минус плата банку за обслуживание счета). Банк это не парит вообще, во всяком случае суммы в 2 млн в год (~160 в месяц) вряд-ли кого-то сильно взволнует.

2) На УСН-6% ты должен государству 120 тыс. рублей с 2 млн (взносы в фонды поглотятся этой суммой т.к. налоги можно уменьшить на сумму взносов, но не более чем на 50%).

2б) на ОСНО - не знаю. Точно надо заплатить НДС, а как оно вообще устроено у ИП в таком случае - х.з, не интересовался.

3) Если ты вывел вообще все на свой счет - ты можешь пойти в сберкассу и через окошко заплатить налоги и в фонды. Хотя при наличии расчетного счета и клиент-банка это как-то глупо.

На практике я на р/с накапливаю те самые 6%, которые причитаются государству и раз в квартал их плачу.

В бинарном - только под винды и мак.

А stl/boost - это "базовые типы", там проверять каждый чих действительно устанешь. Но LibRaw - это 3-4 вызова на файл, можно и проверить бы.

Ну, мысли такие: по идее контракт с пользователем по исключениям ничем логически не отличается от контракта по интерфейсу, и должен оговариваться. Проще всего договорится, что исключения не летят. Т.е. например fread сообщает об ошибке возвращаемым значением или еще чем-то. И пусть пользователь сам в своем объекте это обеспечивает.
Про неизвестные исключения - я не понимаю где и откуда они летят, поэтому сказать ничего не могу. Но если надо все-таки как-то защититься от неразумных пользователей, которые таки кидаются исключениями, то я видел два подхода. Один такой: catch(...), который транслирует неизвестные исключения в какой-нибудь фатальный error code, после которого разрешается только помереть. Вот например SAX-парсер от MSXML именно так и делает - при любых исключениях в callback-ах возвращает какой-то fatal. Для пользователя не очень удобно.
Второй подход: catch(...) -> чистка -> rethrow. Пользователь снаружи LibRaw сможет словить собственные исключения. Но я не знаю как тут с бинарной совместимостью по исключениям, если LibRaw собран одним компилятором, а пользовательский код - другим.
В любом случае, мне кажется, фантазировать "а какой бы мне еще тип исключения словить" не стоит, это контракт.

конкретно std::filebuf у меня внутри, но по сути ты прав.

Есть некоторый (базовый) класс, реализующий абстракцию I/O. По семантике это FILE* (fseek, fread, fscanf) с небольшими нашлепками, которые для сути дела неважны.
У меня в библиотеке реализованы три имплементации этого класса - для маленького файла (полная буферизация в памяти), для большого файла, для буфера в памяти.

Но пользователь может реализовать свое, скажем для сетевого сокета (fseek придется делать чтением до нужного места, но меня это не парит).
И пользовательская реализация может кидать свои исключения.

А дальше этот класс (производный от него) передается в функцию, которая собственно парсит файл с изображением. Или явно передается (пользовательский класс) или неявно (передается имя файла, а дальше на этом файле сделается одна из моих реализаций).

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

Но что делать с неизвестными исключениями? Особенно с учетом того, что они могут просто летать от мультитредности (говорят вот pthreads в винде сделаны частично на исключениях)....

Тогда простите за вредный совет. Лично мою жизнь эта книга сделала существенно проще.

Мнэээ, Полуэкт... Что-то начинает прояснятся, я видимо сначала не понял. ;-) Но все равно не хватает подробностей, приходится фантазировать. У вас C++-интерфейс, из которого ничего не должно вылетать. Но внутри вашего кода исключения есть, и их надо наверху преобразовывать в errorCodes. Так? Видимо std::filebuf - это такой callback, который приходит снаружи как параметр, так? Тогда глотать его исключения (заменять на errorCode) - плохо, потеря информации, пользователь обидится. Я бы оборачивал вызовы callback-а в try-catch с последующим rethrow, а преобразование в errorCode делал только со своими исключениями. Если это возможно. Ну или пробовал бы strict-подход, как рекомендуют выше: вся чистка в деструкторах, наружу сложные объекты с такими деструкторами не торчат, и т.д.
Рассчитывать на то, что пользовательский код будет кидать исключениями определенного типа также не стоит.

Ну, вообще я был уверен, что наружу - только errorcode (тем более, что есть C-интерфейс, какие уж там исключения).
Но несчастный юзер налетел на exception от потрохов (std::filebuf), я не понимаю что должно случиться, чтобы этот filebuf не смог прочитать первые два байта из файла (они там есть!), ну наверное там так ошибка ОС обрабатывается, киданием исключения. Отлично, std::exception от своей имплементации - я поймаю, нивапрос.

Но примерно в то же место пользователь может просунуть свою реализацию потока ввода-вывода, со своими исключениями - и этих я уже не поймаю.

Такое поведение - нормальное? Засунул что-то нестандартное - лови сам!

Да, я понимаю, мне тоже было в лом начинать ее читать :) Но там отдельный небольшие главы, удобно.

Не, я ни разу не призываю ловить фатальные ошибки, после которых только и остается, что ползти на кладбище. ;-) Я только о том, что наличие одновременно двух способов обработки ошибок не есть гут. Если исключению позволяется вылететь наружу, то не надо ему мешать это делать erroCode-ами. Ну, например:
catch( std:exception ) {
аккуратно_склеить_ласты();
throw;
}
Если надо отдельно обрабатывать my_own_exception_type, то его надо отдельно и словить. Но это странный подход, именно по причине двойной обработки ошибок _внутри_ вашего кода.

Почему в деструкторах?

Вот у меня объект LibRaw, он может обработать много файлов. Надо ли ему ломаться и (self-)-деструктиться, если ему подсунули битый файл или такой путь в файловой системе, который не читается?

То есть о деструкторе речь не идет.

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

Исключения в потоках - это отстой, да. Видел только одно решение хорошее - в .NET Framework 4.0.

Обработка ошибки - это же не только показ сообщения об этой ошибке пользователю.

Надо
- аккуратно все позакрывать-поосвобождать (включая всякие промежуточные буферы не на стеке)
- завершить threads (если были)
- ну и вообще, прибрать за собой рабочее место.
То есть в любом случае - нужно на промежуточном уровне (ниже пользователя библиотеки) это все делать.
Ну и сочетание с OpenMP (и прочими lightweight-тредами, вроде TBB) - неиллюзорно доставляет.

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

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