Здравствуйте, drol, Вы писали:
D>>>Где Вы это увидели ??? "should generally", да ещё и в каком-то там примечании это определённо не запрет. _FR>>Что значит "где"? D>Э-э-э... Вам объяснить как переводится выражение с "should generally" ? И чем примечание отличается от собственно текста пункта "Стандарта" ?
Согласен, с "явно запрещено" я переборщил.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, drol, Вы писали:
D>Здравствуйте, catBasilio, Вы писали:
B>>исключение вышедшее за границы деструктора — результат вызов terminate() и завершение программы.
D>Ничего подобного. terminate() будет только если исключение выброшено из деструктора в ходе раскрутки стека. Во всех остальных случаях проблем нет.
Пример остальных случаев пожалуйста.
UNIX way — это когда тебе вместо туалетной бумаги дают топор, рубанок и карту близлежащего леса
Здравствуйте, drol, Вы писали:
D>Здравствуйте, Aviator, Вы писали:
A>>Не хочу ввязываться в дискуссию, представьте на досуге что будет в c#, если ресурс A агрегирует ресурс B, который в свою очередь агрегирует С. Ресурсы B и C надо явно освободить по освобождению A.
D>А теперь представьте, что в процессе освобождения ресурса C произошла ошибка, и информацию об оной нужно отправить дальше по callstack'у тем, кто знает что в этом случае делать.
И что вы будете делать с ошибкой при освобождении ресурса выше по стеку если не секрет?
ЗЫ При исключении из диспоуза вас не смущает, что часть ресурсов корректно освобождена а часть повисла в непонятном состоянии?
Здравствуйте, Lloyd, Вы писали:
L>Зачем что-то еще?
Дядька — using тоже синтаксический сахар finally с IDisposable. Вопрос другой, что выглядит лучше и понятней, поэтому используют именно его, а не finally. Я широко использую using без освобождения ресурсов. В этом случае прекрасно видны границы работы функций. Но для этого приходится генерить прокси классы.
Здравствуйте, GlebZ, Вы писали:
GZ>Дядька — using тоже синтаксический сахар finally с IDisposable. Вопрос другой, что выглядит лучше и понятней, поэтому используют именно его, а не finally. Я широко использую using без освобождения ресурсов. В этом случае прекрасно видны границы работы функций. Но для этого приходится генерить прокси классы.
Я использую хелпер.
class Scope: IDisposable
{
private readonly Action onDispose;
public Scope(Action onDispose)
{
this.onDispose = onDispose;
}
public void Dispose()
{
onDispose();
}
}
// пример использованияpublic IDisposable InTransaction(IsolationLevel isolationLevel = IsolationLevel.ReadCommitted)
{
BeginTransaction(isolationLevel);
return new Scope(() =>
{
if (Transaction != null)
CommitTransaction();
});
}
void foo()
{
using (InTransaction())
{
// some logic
}
}
Здравствуйте, catBasilio, Вы писали:
B>Здравствуйте, drol, Вы писали:
D>>Здравствуйте, catBasilio, Вы писали:
B>>>исключение вышедшее за границы деструктора — результат вызов terminate() и завершение программы.
D>>Ничего подобного. terminate() будет только если исключение выброшено из деструктора в ходе раскрутки стека. Во всех остальных случаях проблем нет.
B>Пример остальных случаев пожалуйста.
Здравствуйте, drol, Вы писали:
D>Здравствуйте, Angler, Вы писали:
A>>Возможность существования никто и не отрицает.
D>Так зачем Вы тогда пытались заболтать тему, ежели согласны с ложностью выдвинутого "конкурирующей организацией" тезиса
Возможность то есть, но за наличие трывают руки(как вариант — отрезаешь себе со временем уши). Такой себе сферический конь в вакууме..
Здравствуйте, drol, Вы писали:
D>Здравствуйте, Aviator, Вы писали:
A>>Не хочу ввязываться в дискуссию, представьте на досуге что будет в c#, если ресурс A агрегирует ресурс B, который в свою очередь агрегирует С. Ресурсы B и C надо явно освободить по освобождению A.
D>А теперь представьте, что в процессе освобождения ресурса C произошла ошибка, и информацию об оной нужно отправить дальше по callstack'у тем, кто знает что в этом случае делать.
а что делать с ошибкой, которая привела к вызову Dispose и информацию о которой тоже нужно отправить дальше?
Здравствуйте, GlebZ, Вы писали:
L>>Зачем что-то еще? GZ>Дядька — using тоже синтаксический сахар finally с IDisposable.
Спасибо, мальчик. Ты решил поиграть в капитана? Похвально.
GZ>Вопрос другой, что выглядит лучше и понятней, поэтому используют именно его, а не finally.
Уверяю тебя, тот код, котрый ты привел точно не используют, т.к. он даже не скомпилится.
GZ>Я широко использую using без освобождения ресурсов. В этом случае прекрасно видны границы работы функций. Но для этого приходится генерить прокси классы.
Тот вариант, что ты привел — весьма сомнителен. Если уж хочется непременно использовать using, то можно придумать более понятные варианты даже не выходя за рамки существующего языка.
Здравствуйте, HowardLovekraft, Вы писали:
HL>Здравствуйте, Aviator, Вы писали:
A>>А вообще, using это каменный век по сравнению с работой деструкторов... HL>Толсто троллите.
Это крик души
Здравствуйте, Aviator, Вы писали:
A>И что вы будете делать с ошибкой при освобождении ресурса выше по стеку если не секрет?
Что захочу, то и сделаю. В рамках примера с распределённой транзакцией — можно просто сразу повторить транзакцию, можно зашедулить повторение через таймаут, можно написать в лог, можно спросить пользователя, можно проанализировать причину отказа и выдать рекомендации и т.д., и т.п., и даже всё сразу
A>ЗЫ При исключении из диспоуза вас не смущает, что часть ресурсов корректно освобождена а часть повисла в непонятном состоянии?
Ничто и нигде не повисло — catch\finally-блоки обо всём позаботятся. В отличии от деструкторов С++ им ведь доступна вся информация о ситуации.
Здравствуйте, drol, Вы писали:
D>Здравствуйте, Aviator, Вы писали:
A>>И что вы будете делать с ошибкой при освобождении ресурса выше по стеку если не секрет?
D>Что захочу, то и сделаю. В рамках примера с распределённой транзакцией — можно просто сразу повторить транзакцию, можно зашедулить повторение через таймаут, можно написать в лог, можно спросить пользователя, можно проанализировать причину отказа и выдать рекомендации и т.д., и т.п., и даже всё сразу
Проанализировать причину отказа при освобождении ресурса? Что курим? Может мессаджбокс ещё юзеру покажешь "Извини, не могу освободить ресурс" ?
A>>ЗЫ При исключении из диспоуза вас не смущает, что часть ресурсов корректно освобождена а часть повисла в непонятном состоянии?
D>Ничто и нигде не повисло — catch\finally-блоки обо всём позаботятся. В отличии от деструкторов С++ им ведь доступна вся информация о ситуации.
Что им доступно, ты не освободил половину ресурсов, половина уже грохнута, причём последний вызов завершился с исключением. Что будет при убивании оставшейся половины — одному богу известно и будет отлично проглочено при вызове финализатора.
Здравствуйте, Aviator, Вы писали:
A>Проанализировать причину отказа при освобождении ресурса?
Ага. Например, если транзакция не прошла, и я вижу в цепочках исключений какой-нибудь SocketClosedByTimeoutException, то можно проверить состояние сети, видимость сервера и т.п. И, соответственно, много чего интеллектуального сделать на эту тему — поставить мониторинг на восстановление связи, зашедулить повтор транзакции и т.д.
A>Что курим?
Да уж явно не то что освободители ресурсов в деструкторах глотающие все ошибки
A>Может мессаджбокс ещё юзеру покажешь "Извини, не могу освободить ресурс" ?
Если есть разумный use case с UI — конечно же покажу.
A>Что им доступно, ты не освободил половину ресурсов, половина уже грохнута, причём последний вызов завершился с исключением.
Вот именно что с исключением. А нормальное исключение явно говорит в чём проблема.
A>Что будет при убивании оставшейся половины — одному богу известно
Насчёт бога не знаю, а вот мне обычно прекрасно известно что может быть. Программные системы они того — детерминированные, знаете ли.
A>и будет отлично проглочено при вызове финализатора.
Финализатор здесь совершенно не при делах, бо он вызывается в случае, когда информация об ошибочных ситуациях как раз не нужна. И деструкторы C++ как раз являются аналогом финализатора в этом плане.
Здравствуйте, Aviator, Вы писали:
A>То что в при исключении не все диспоузы отработают
С каких это ??? В общем случае все finally-блоки по пути всегда исполняются. Если нужна более сложная схема — пожалуйста, можно явные catch'и понаписать, и логику освобождения какую душе угодно.
Здравствуйте, drol, Вы писали:
D>Здравствуйте, Aviator, Вы писали:
A>>То что в при исключении не все диспоузы отработают
D>С каких это ??? В общем случае все finally-блоки по пути всегда исполняются. Если нужна более сложная схема — пожалуйста, можно явные catch'и понаписать, и логику освобождения какую душе угодно.
Здравствуйте, Lloyd, Вы писали:
L>Спасибо, мальчик. Ты решил поиграть в капитана? Похвально.
Ты что, обиделся? Это просто у меня такое выражение. Ничего личного, и никого не хотел оскорбить.
GZ>>Вопрос другой, что выглядит лучше и понятней, поэтому используют именно его, а не finally. L>Уверяю тебя, тот код, котрый ты привел точно не используют, т.к. он даже не скомпилится.
Тот код который я привел как не является юзингом, так и не являеся кодом. Это просто пример.
И вообще, я говорю о двух недостатках using, который ограничивает его использование:
1. Привязка к IDisposable
2. Привязка к finally.
По первой понятно из кода. По второй, я грешен не указал, — мы не имеем информации как мы пролетаем по finally, через exception или нормальным исполнением.
GZ>>Я широко использую using без освобождения ресурсов. В этом случае прекрасно видны границы работы функций. Но для этого приходится генерить прокси классы. L>Тот вариант, что ты привел — весьма сомнителен. Если уж хочется непременно использовать using, то можно придумать более понятные варианты даже не выходя за рамки существующего языка.
Ну да. Например: этот
. Я счас присмотрелся, пример интересный, но неправильный. В случае exception транзакция подтвердится.
Попробуй напиши правильно, чтобы можно было делать а ля ScopeTransaction но без явного и бесполезного указания Commit.
Здравствуйте, Aviator, Вы писали:
A>У тебя из finally вылетает исключение
Да без разницы откуда оно вылетает — finally-блоки поэтому и finally, бо в нормальном потоке исполнения они отрабатывают в независимости от того что и откуда вылетело. Если в finally нужна логика в которой возможны свои исключения — ну так пишите try\catch и ловите их там.
Здравствуйте, GlebZ, Вы писали:
GZ>>>Вопрос другой, что выглядит лучше и понятней, поэтому используют именно его, а не finally. L>>Уверяю тебя, тот код, котрый ты привел точно не используют, т.к. он даже не скомпилится. GZ>Тот код который я привел как не является юзингом, так и не являеся кодом. Это просто пример.
О том и речь. Потому говорить "используют именно его" некорректно.
L>>Тот вариант, что ты привел — весьма сомнителен. Если уж хочется непременно использовать using, то можно придумать более понятные варианты даже не выходя за рамки существующего языка. GZ>Ну да. Например: этот
. Я счас присмотрелся, пример интересный, но неправильный. В случае exception транзакция подтвердится. GZ>Попробуй напиши правильно, чтобы можно было делать а ля ScopeTransaction но без явного и бесполезного указания Commit.
Там просто не надо было использовать using, он там не нужен.
