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

D>Здравствуйте, -MyXa-, Вы писали:

MX>>Пример в первом сообщении этой ветки.

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

Общее правило с++ деструкторы — не могут кидать исключения. Так что с обработкой ошибок\исключений там все замечательно.

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

B>Общее правило с++ деструкторы — не могут кидать исключения.

Нет такого правила в "Стандарте" В C++ деструкторы вполне себе могут бросать исключения. Просто потенциально возможные последствия оных "бросков" не устраивают пользователей языка

B>Так что с обработкой ошибок\исключений там все замечательно.

Ну как же "замечательно", если по Вашим словам выходит, что она невозможна ??? Тогда как нормальная работа с любым нетривиальным ресурсом, повторяю пример — распределённая транзакция, нуждается в этих механизмах.

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

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

A>>Здравствуйте, -MyXa-, Вы писали:

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

B>>>>собственно сабж. с помощью него в с++ очень удобно организовывать RAII. пример:

MX>>>Краткое объяснение здесь
A>>А вообще, using это каменный век по сравнению с работой деструкторов...

А>а пояснить примером можете?
А>желатеельно в сравнении
Не хочу ввязываться в дискуссию, представьте на досуге что будет в c#, если ресурс A агрегирует ресурс B, который в свою очередь агрегирует С. Ресурсы B и C надо явно освободить по освобождению A.

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

A>Не хочу ввязываться в дискуссию, представьте на досуге что будет в c#, если ресурс A агрегирует ресурс B, который в свою очередь агрегирует С. Ресурсы B и C надо явно освободить по освобождению A.

А теперь представьте, что в процессе освобождения ресурса C произошла ошибка, и информацию об оной нужно отправить дальше по callstack'у тем, кто знает что в этом случае делать.

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

B>>Общее правило с++ деструкторы — не могут кидать исключения.
D>Нет такого правила в "Стандарте" В C++ деструкторы вполне себе могут бросать исключения. Просто потенциально возможные последствия оных "бросков" не устраивают пользователей языка

ISO/IEC 14882
Second edition 2003-10-15
15.2 Constructors and destructors [except.ctor], абзац 3

The process of calling destructors for automatic objects constructed on the path from a try block to a
throw-expression is called “stack unwinding.” [Note: If a destructor called during stack unwinding exits
with an exception, terminate is called (15.5.1). So destructors should generally catch exceptions and
not let them propagate out of the destructor. —end note]

То есть в стандарте явно запрещено выбрасывание чего-либо из деструктора.

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

GZ>>>Счас на таких задачах приходится Dispose прокси делать.

L>>

L>>try {
L>>  t.Start();
L>>} finally {
L>>  t.Stop();
L>>}
L>>

L>>Зачем что-то еще?

B>в с++ за такой код полагается руки отрывать.

Во-первых, в с++ нет finally.
А во-вторых, вопрос о том, чем вариант GlebZ-а лучше варианта с finally.

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

_FR>То есть в стандарте явно запрещено выбрасывание чего-либо из деструктора.

Где Вы это увидели ??? "should generally", да ещё и в каком-то там примечании это определённо не запрет.

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

_FR>>То есть в стандарте явно запрещено выбрасывание чего-либо из деструктора.

D>Где Вы это увидели ??? "should generally", да ещё и в каком-то там примечании это определённо не запрет.

Что значит "где"?

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

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

GZ>>>>Счас на таких задачах приходится Dispose прокси делать.

L>>>

L>>>try {
L>>>  t.Start();
L>>>} finally {
L>>>  t.Stop();
L>>>}
L>>>

L>>>Зачем что-то еще?

B>>в с++ за такой код полагается руки отрывать.

L>Во-первых, в с++ нет finally.
L>А во-вторых, вопрос о том, чем вариант GlebZ-а лучше варианта с finally.

ничем не лучше. Оба кривые.
В продакшин коде может сложиться ситуация, когда между try и finally будет помещено много кода разными коммитерами в разное время. И очень высока вероятность, что кто-нибудь просто по невнимательности забудет написать в finally освобождение ресурса.

код с using немного лучше, но это только для блока. непонятно как это юзать для мемберов класса. Кроме того надо не забыть в Dispose явно освободить ресурс. Что чревато, как и в первом случае.

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

D>>Где Вы это увидели ??? "should generally", да ещё и в каком-то там примечании это определённо не запрет.

_FR>Что значит "где"?

Э-э-э... Вам объяснить как переводится выражение с "should generally" ? И чем примечание отличается от собственно текста пункта "Стандарта" ?

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

B>>>в с++ за такой код полагается руки отрывать.

L>>Во-первых, в с++ нет finally.
L>>А во-вторых, вопрос о том, чем вариант GlebZ-а лучше варианта с finally.

B>ничем не лучше. Оба кривые.
B>В продакшин коде может сложиться ситуация, когда между try и finally будет помещено много кода разными коммитерами в разное время. И очень высока вероятность, что кто-нибудь просто по невнимательности забудет написать в finally освобождение ресурса.

А в с++ вероятность того, что кто-то не напишет нужную обертку, видимо нулевая?

B>код с using немного лучше, но это только для блока. непонятно как это юзать для мемберов класса. Кроме того надо не забыть в Dispose явно освободить ресурс. Что чревато, как и в первом случае.

Вы зря не посмотрели код GlebZ. Там, гм, не совсем using.

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

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

_FR>>То есть в стандарте явно запрещено выбрасывание чего-либо из деструктора.

D>Где Вы это увидели ??? "should generally", да ещё и в каком-то там примечании это определённо не запрет.

исключение вышедшее за границы деструктора — результат вызов terminate() и завершение программы.

15.5.1 The std::terminate() function
1
[except.terminate]
In the following situations exception handling must be abandoned for less subtle error handling techniques:
— when the exception handling mechanism, after completing evaluation of the expression to be thrown but before
the exception is caught (15.1), calls a user function that exits via an uncaught exception,140)
— when the exception handling mechanism cannot find a handler for a thrown exception (15.3), or
— when the destruction of an object during stack unwinding (15.2) exits using an exception, or

и еще

15.3
Handling an exception
The process of calling destructors for automatic objects constructed on the path from a try block to a throw-expression is
called “stack unwinding.” [ Note: If a destructor called during stack unwinding exits with an exception, std::termin-
ate is called (15.5.1). So destructors should generally catch exceptions and not let them propagate out of the destructor.
— end note ]

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


L>А в с++ вероятность того, что кто-то не напишет нужную обертку, видимо нулевая?

Если не допускать на уровне code review чтобы мемчерами класса были сырые указатели (за некоторыми исключениями) — то да, почти нулевая.

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

B>исключение вышедшее за границы деструктора — результат вызов terminate() и завершение программы.

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

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

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

B>>исключение вышедшее за границы деструктора — результат вызов terminate() и завершение программы.

D>Ничего подобного. terminate() будет только если исключение выброшено из деструктора в ходе раскрутки стека. Во всех остальных случаях проблем нет.

Дык дело в том, что "правильного" метода, для определения, был ли вызван деструктор вызван в процессе расскрутки после выброса исключения, или в "обычном" режиме, — НЕТ.

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

A>А вообще, using это каменный век по сравнению с работой деструкторов...

А вообще, красное — холоднее, чем дырявое...
Ну а по теме: пишешь на шарпе после на плюсов — не хватает дестукторов, оператора->, а так-же шаблонов. При пеходе в другом направлении, не хватает вообще ничего. А вот если писать параллельно и на том и на том, в зависимости от задач, имея определённый опыт, то всё пучком

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

A>Дык дело в том, что "правильного" метода, для определения, был ли вызван деструктор вызван в процессе расскрутки после выброса исключения, или в "обычном" режиме, — НЕТ.

Наличие\отсутствие такого метода — обсуждаемому вопросу совершенно ортогонально. Корректная C++ программа, реально бросающая исключение из деструктора и не финиширующая в этой связи через terminate() и прочие нездоровые вещи, всё равно возможна.

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

D>Наличие\отсутствие такого метода — обсуждаемому вопросу совершенно ортогонально. Корректная C++ программа, реально бросающая исключение из деструктора и не финиширующая в этой связи через terminate() и прочие нездоровые вещи, всё равно возможна.

Возможность существования никто и не отрицает. Правда на все такие программы накладывается одно жёсткое требование — в деструкторе необходимо знать контекст использования обьекта. Соответвственно и в месте использования такого обьекта необходимо знать, с каким "гадом" имеешь дело.
Этот вопрос перетирался на плюсовом форуме n-раз.

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

A>Возможность существования никто и не отрицает.

Так зачем Вы тогда пытались заболтать тему, ежели согласны с ложностью выдвинутого "конкурирующей организацией" тезиса

*Вопрос риторический

С этим разобрались, возвращаемся к исходной теме: как всё-таки оппоненты using\IDisposable предлагают решать дежурную задачу проноса информации об исключительных ситуациях, возникших при освобождении ресурса, в случае цепочки автоматических вызовов деструкторов ?

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

A>При пеходе в другом направлении, не хватает вообще ничего.

Вы всё-таки видимо хотели сказать "не хватает вообще всего"