Здравствуйте, Roman Odaisky, Вы писали:

RO>Здравствуйте, merk, Вы писали:

M>>не делайте throw, если вы обработали исключение.
M>>раз вы его делаете, это значит, что вы не можете исключение реально обработать.

RO>Это он изображает finally.

RO>Кстати, как можно иначе сделать вот это:
RO>

RO>context.begin();
RO>try
RO>{
RO>    . . .
RO>}
RO>catch(...)
RO>{
RO>    context.rollback();
RO>    throw;
RO>}
RO>context.commit();
RO>

RO>?

M>>вообще это моветон, программировать "на исключениях", моду на такое пресекать нуна!

RO>А как правильно?

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

Здравствуйте, merk, Вы писали:

M>чтобы было правильно, сначала нужно строго сформулировать условия когда должны возникать исключения.
M>исключение сигнализирует о том, что сложно написать нормальное продолжение алгоритма, при такой вот ситуации.
M>еще строже — когда функция выполняет предусловия, но не может никаким образом выполнить постусловия. то есть нет выхода из функции регулярным образом.
M>теперь вопрос — если у вас что-то сломалось в базе и вы либо откатываетесь, либо завершаете транзакцию...действительно это настолько разрушительно для вашего алгоритма, что вы не можете выйти из функции?
M>нет.
M>ситуаций для эксепшенов, на самом деле — на пальцах перечесть. и народ кидает эксепшены в 90 проц. случаях совершенно излишне.

Т. е., ты предлагаешь заменять исключения кодами возврата?

А>Это не проблема языка. Это проблема команды, и личной дисциплины каждого. Есть coding style проекта, за любое отступление от него должно биться по рукам и производиться обязательное "выправление". Если не согласны со стилем — все вопросы к лидеру проекта. Но пока он не одобрит изменения в coding style — все должны пищать, но соответствовать текущему варианту. Ибо нефиг.
Вы просто думаете с точки зрения программера. А с точки зрениия руководства фирмы дополнительная поддержка дисциплины в конечном итоге выливается в дополнительные материальные расходу — на оплату более квалифицированных манагеров, архитектов да и самих программеров, да и битье по рукам и переписывание кода — это затраты времени, которое тоже стоит денег.

Здравствуйте, Roman Odaisky, Вы писали:

RO>Здравствуйте, merk, Вы писали:

M>>чтобы было правильно, сначала нужно строго сформулировать условия когда должны возникать исключения.
M>>исключение сигнализирует о том, что сложно написать нормальное продолжение алгоритма, при такой вот ситуации.
M>>еще строже — когда функция выполняет предусловия, но не может никаким образом выполнить постусловия. то есть нет выхода из функции регулярным образом.
M>>теперь вопрос — если у вас что-то сломалось в базе и вы либо откатываетесь, либо завершаете транзакцию...действительно это настолько разрушительно для вашего алгоритма, что вы не можете выйти из функции?
M>>нет.
M>>ситуаций для эксепшенов, на самом деле — на пальцах перечесть. и народ кидает эксепшены в 90 проц. случаях совершенно излишне.

RO>Т. е., ты предлагаешь заменять исключения кодами возврата?
я предлагаю любую замену исключениям, там где возможны варианты исполнения вашей задачи.
если вы открываете файл, коотрого нет...это не значит, что это нельзя обработать регулярным образом. о чем свидетельствует исключение.
код возврата, например.

Здравствуйте, merk, Вы писали:

M>давно с дельфи имел дело...а там можно экземпляры классов располагать на стеке? или делают их только на куче?

только в куче.
соответственно, членами класса могут быть только ссылки на объекты, которые вполне законно инициализировать нулем.
одно другое тянет

Здравствуйте, merk, Вы писали:

RO>>Т. е., ты предлагаешь заменять исключения кодами возврата?
M>я предлагаю любую замену исключениям, там где возможны варианты исполнения вашей задачи.
M>если вы открываете файл, коотрого нет...это не значит, что это нельзя обработать регулярным образом. о чем свидетельствует исключение.
M>код возврата, например.

Ну это древний флейм, исключения против кодов возврата. Вроде уже единогласно решили, что исключения лучше, кроме случаев, когда они значительно вредят производительности.

Исключения не позволяют проигнорировать проблему и отделяют основную работу от обработки ошибок.

Самый простой пример — try { document.save(); } catch(std::exception const& e) { alert(text="Failure saving document", details=e.what()); }. И всё. С кодами возврата задолбаешься проверять успешность каждой операции.

Здравствуйте, Roman Odaisky, Вы писали:

RO>Здравствуйте, merk, Вы писали:

RO>>>Т. е., ты предлагаешь заменять исключения кодами возврата?
M>>я предлагаю любую замену исключениям, там где возможны варианты исполнения вашей задачи.
M>>если вы открываете файл, коотрого нет...это не значит, что это нельзя обработать регулярным образом. о чем свидетельствует исключение.
M>>код возврата, например.

RO>Ну это древний флейм, исключения против кодов возврата. Вроде уже единогласно решили, что исключения лучше, кроме случаев, когда они значительно вредят производительности.

RO>Исключения не позволяют проигнорировать проблему и отделяют основную работу от обработки ошибок.

RO>Самый простой пример — try { document.save(); } catch(std::exception const& e) { alert(text="Failure saving document", details=e.what()); }. И всё. С кодами возврата задолбаешься проверять успешность каждой операции.

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

Здравствуйте, merk, Вы писали:

M>опять же ошибки нужно обрабатывать как можно ближе к месту их возникновения. а — далеко выпрыгивать — противоречит данному принципу.

бессмысленный принцип.

Ошибки нужно обрабатывать там, где ты можешь их адекватно обработать, в зависимости от тяжести ошибки.
А далеко это или близко окажется от места возникновения ошибки — дело десятое.

You will always get what you always got
  If you always do  what you always did

Здравствуйте, merk, Вы писали:

M>этот мир так устроен, что любая идиотская мысль, всегда подтверждается изящным примером.
M>если вас задолбит код возврата,...то обработка исключений задолбит еще больше.
Видимо симметрия мира требует считать, что и твоя идиотская мысль подтверждается изящными примерами?

OK, примеры в топку.

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

IMHO, есть намного более прямой главный и обязательный принцип. Обработка ошибок и исключительных ситуаций должна иметь в программе цельный и продуманный характер.
Можно сделать и цельную и стройную обработку на кодах возврата и на исключениях, и на длинных джампах и много ещё на чём. Только сначала надо продумать и спроектировать логичную систему, а потом уж отвечать на вопросы про исключения там или коды возврата...

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, merk, Вы писали:

M>>этот мир так устроен, что любая идиотская мысль, всегда подтверждается изящным примером.
M>>если вас задолбит код возврата,...то обработка исключений задолбит еще больше.
E>Видимо симметрия мира требует считать, что и твоя идиотская мысль подтверждается изящными примерами?

E>OK, примеры в топку.

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

E>IMHO, есть намного более прямой главный и обязательный принцип. Обработка ошибок и исключительных ситуаций должна иметь в программе цельный и продуманный характер.

Это не принцип. Это бла-бла.

E>Можно сделать и цельную и стройную обработку на кодах возврата и на исключениях, и на длинных джампах и много ещё на чём. Только сначала надо продумать и спроектировать логичную систему, а потом уж отвечать на вопросы про исключения там или коды возврата...

Здравствуйте, jazzer, Вы писали:

J>Здравствуйте, merk, Вы писали:

M>>опять же ошибки нужно обрабатывать как можно ближе к месту их возникновения. а — далеко выпрыгивать — противоречит данному принципу.

J>бессмысленный принцип.

J>Ошибки нужно обрабатывать там, где ты можешь их адекватно обработать, в зависимости от тяжести ошибки.
J>А далеко это или близко окажется от места возникновения ошибки — дело десятое.

раз пошла такая пьянка.
софт ващета не должен падать с правильной диагностикой, а система должна стараться ошибку локализовать, изолировать, исправить.
из принципа локализации уже видно, что ...читай мое выше — как можно ближе к месту возникновения...
принцип изоляции говорит о том же. что логически не относящиеся к ошибочной ситуации узлы, процедуры, компоненты и модули и все такое, вплоть до контекстов не должны быть вовлечены в изоляцию ошибки.
поотму проброс ошибки вверх по контексту и радостное сообщение юзеру — "привет, мы упали!" не является хорошим методом обработки ошибок, и также случаем функционирования правильной системы, ну в моем конешна понимании.

Здравствуйте, merk, Вы писали:

M>Здравствуйте, jazzer, Вы писали:

J>>Здравствуйте, merk, Вы писали:

M>>>опять же ошибки нужно обрабатывать как можно ближе к месту их возникновения. а — далеко выпрыгивать — противоречит данному принципу.

J>>бессмысленный принцип.

J>>Ошибки нужно обрабатывать там, где ты можешь их адекватно обработать, в зависимости от тяжести ошибки.
J>>А далеко это или близко окажется от места возникновения ошибки — дело десятое.

M>раз пошла такая пьянка.
M>софт ващета не должен падать с правильной диагностикой, а система должна стараться ошибку локализовать, изолировать, исправить.
M>из принципа локализации уже видно, что ...читай мое выше — как можно ближе к месту возникновения...
M>принцип изоляции говорит о том же. что логически не относящиеся к ошибочной ситуации узлы, процедуры, компоненты и модули и все такое, вплоть до контекстов не должны быть вовлечены в изоляцию ошибки.
M>поотму проброс ошибки вверх по контексту и радостное сообщение юзеру — "привет, мы упали!" не является хорошим методом обработки ошибок, и также случаем функционирования правильной системы, ну в моем конешна понимании.

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

You will always get what you always got
  If you always do  what you always did

Здравствуйте, merk, Вы писали:

E>>IMHO, есть намного более прямой главный и обязательный принцип. Обработка ошибок и исключительных ситуаций должна иметь в программе цельный и продуманный характер.

M>Это не принцип. Это бла-бла.

IMHO, Это не реплика, а очень аргументированная заявка на высокий профессиональный уровень тебя, как проектировщика и программиста...

Может перейдёшь от навешивания ярлыков к аргументам? От чего тебе кажется, что продумывать систему обработки исключительных ситуаций не нужно? Или ты что-то другое хотел сказать?

Здравствуйте, jazzer, Вы писали:

M>>раз пошла такая пьянка.
M>>софт ващета не должен падать с правильной диагностикой, а система должна стараться ошибку локализовать, изолировать, исправить.
M>>из принципа локализации уже видно, что ...читай мое выше — как можно ближе к месту возникновения...
M>>принцип изоляции говорит о том же. что логически не относящиеся к ошибочной ситуации узлы, процедуры, компоненты и модули и все такое, вплоть до контекстов не должны быть вовлечены в изоляцию ошибки.
M>>поотму проброс ошибки вверх по контексту и радостное сообщение юзеру — "привет, мы упали!" не является хорошим методом обработки ошибок, и также случаем функционирования правильной системы, ну в моем конешна понимании.

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

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

Здравствуйте, merk, Вы писали:

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

Что такое контекст возникновения исключительной ситуации?
Это функция, которая кинула исключение, та которая ее непосредственно вызвала?
Насколько в стеке вызова распространяется допустимый дипазон для обработки исключения?

Imho, все зависит от разбиения на логические подсистемы, а размер стека вызовов значения не имеет.
Нехорошо выводить на уровень пользовательского интерфейса std::out_of_range, т.к. для пользователя
сообщение бессмысленное. А коды возврата — в топку. Их случайное игнорирование множит количество
неучтенных сценариев выполнения программы, не всегда приводящих к явной и быстрой смерти, а чаще к странным глюкам
и порче важных данных.

З.Ы. Пример с откатом транзакции в деструкторе scope guard'а — удачный. У меня в большом проекте, где активно
юзается MS SQL, повсеместно применяется. Это ОЧЕНЬ удобно, такое количество кода с использованием кодов возврата
поддерживать было бы просто НЕРЕАЛЬНО.

Здравствуйте, merk, Вы писали:

M>1. совместимость с С. в С просто видна история развития и затыкание синтаксических дыр.
M>например значок -> как сокращение косорукой(из-за лексики С) необходимой записи (*p).name.
M>авторы С явно сначала и не думали использовать структурные типы, и видимо клепали точное подобие какого-нить ассемблера PDP-11. по крайней мере чтобы при не особосложном компиляторе получить прямое отображение С в ассемблер.

После паскаля, думаю, сложно понять язык. Это ничто иное, как современный стандартизованный (кроссплатформенный) ассемблер. К сведению — традиционные ассемблеры сейчас могут переплюнуть в метапрограммировании любые шаблоны. Только писанины там будет... Да и не используют макросы настоящие джедаи (real men code in hex), вот Страуструп тоже устал писать на традиционном ассемблере...

Здравствуйте, remark,

(еще не дочитал ветку )

Не мешает, но несколько напрягает сложность языка. В том смысле, что отражается это на сложности транслятора. Иной раз не понять, насколько кривые у тебя руки, когда минимальный пример работает нормально, а большой код ломается в зависимости от ключей компилятора. У производителей компиляторов то руки по определению правильные, багов в них не бывает

Или internal compiler error — очень вразумительное сообщение об ошибке

Здравствуйте, Alexander G, Вы писали:

AG>std::function — не на уровне языка

Тем неменее оно будет в

Standard for Programming Language C++

new, dynamic_cast<>, исключения, ... тоже "не на уровне", требуют поддержку рантаймом...

Здравствуйте, gear nuke, Вы писали:

AG>>std::function — не на уровне языка

GN>Тем неменее оно будет в
GN>

Standard for Programming Language C++

Ага. Будет как сейчас vector или string. Шаблонный класс, а не встроенная в язык конструкция. Недостатки:

Легче использовать неправильно.
Труднее смотреть в отладчике.
Мешает, а не помогает оптимизации.
Больше свои тараканов у каждой реализации.

GN>new, dynamic_cast<>, исключения, ... тоже "не на уровне", требуют поддержку рантаймом...

Да, но это уже действительно элменты языка.

Вот кстати лямбда будет тоже элементом языка.
Причём как в lambda, так и в function ничего особого в рантайм добалять не надо.

Не то чтобы мне сильно хотелось чтобы std::function была частью языка, но всё же было бы лучше именно так.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, merk, Вы писали:

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

А>Что такое контекст возникновения исключительной ситуации?
вы вообще сначала сформулируйте — что такое исключительная ситуация. вот как вам кажется?
А>Это функция, которая кинула исключение, та которая ее непосредственно вызвала?
вполне возможно.
А>Насколько в стеке вызова распространяется допустимый дипазон для обработки исключения?
ну вы барин и вопросы задаете... допустимый диапазон — разный. в зависимости от вашей методы обработки ошибок. и что вы считаете ошибками, а что — возможностями. например вы открываете файл..а его нет. это ошибка или возможность? тут нужно генерить исключение, или как-то иначе обрабатывать? и где обрабатывать?

А>З.Ы. Пример с откатом транзакции в деструкторе scope guard'а — удачный. У меня в большом проекте, где активно
А>юзается MS SQL, повсеместно применяется. Это ОЧЕНЬ удобно, такое количество кода с использованием кодов возврата
А>поддерживать было бы просто НЕРЕАЛЬНО.
пример потому и удачный, что вам дали внешний метод исправления ситуации — откат транзакций. вам осталось только его вызвать. кстати где пример-то?
действительно. когда есть много каких-то действий и известно как восстановиться после неустранимой ошибки внутри них, невзирая на глубину вызовов — оченно подходят эксепшены.
но это как раз и есть ситауция, когда их следует применять. я же не говорил что ексепшены вообще не нужны в принципе.
но просто кидать рядовые ошибки с их помощью — неразумно.