Правильная замена отсутствующего 'finally' в C++
Поскольку вместо этого в шаблоне проектирования C++ вы должны использовать RAII нет finally, если вы хотите, чтобы ваш код был безопасным в отношении исключений. Один из способов сделать это - использовать деструктор локального класса, например:
void foo() {
struct Finally {
~Finally() { /* cleanup code */ }
} finalizer();
// ...code that might throw an exception...
}
Это большое преимущество перед простым решением, потому что вам не нужно писать код очистки 2 раза:
try {
// ...code that might throw an exception...
// cleanup code (no exception)
} catch (...) {
// cleanup code (exception)
throw;
}
Большой недостаток решения локального класса заключается в том, что вы не можете напрямую обращаться к локальным переменным в вашем коде очистки. Так что это сильно раздувает ваш код, если вам нужен доступ к ним, несмотря ни на что:
void foo() {
Task* task;
while (task = nextTask()) {
task->status = running;
struct Finally {
Task* task;
Finally(Task* task) : task(task) {}
~Finally() { task->status = idle; }
} finalizer(task);
// ...code that might throw an exception...
}
}
Итак, мой вопрос: Есть решение, которое сочетает в себе оба преимущества? Так что вам а) не нужно писать повторяющийся код и б) иметь доступ к локальным переменным в коде очистки, как task в последнем примере, но без такого раздувания кода.
+1 за то, что спрашиваю об этом, потому что люди, не знакомые с RAII, часто думают, что finally - это хорошо ...
«вам не нужно писать код очистки 2 раза». Зачем вам вообще писать код дважды по какой-либо причине? Вот для чего нужны подпрограммы = P Нейтрально в вопросе RAII vs finally, но написание кода дважды - отвлекающий маневр: вы можете создать процедуру очистки, передать ей задачу и вызвать ее в двух местах. Дублирование кода не требуется. В вашем простом примере это логически является частью деструктора задачи. Но если есть какая-то причина, по которой вы хотите очистить foo, создайте там локальную процедуру очистки.
Ответы 6
Я не думаю, что есть более чистый способ добиться того, что вы пытаетесь сделать, но я думаю, что основная проблема с «окончательным подходом» в вашем примере - это неправильный разделение проблем.
Например. функция foo () отвечает за согласованность объекта Task, это редко бывает хорошей идеей, сами методы Task должны нести ответственность за установку статуса на что-то разумное.
Я действительно понимаю, что иногда есть реальная потребность в finally, и ваш код, очевидно, является всего лишь простым примером, чтобы показать точку, но такие случаи редки. И в редких случаях меня устраивает немного более надуманный код.
Я пытаюсь сказать, что вам редко нужны конструкции finally, и в тех немногих случаях, когда вы это делаете, я бы посоветовал не тратить время на создание более приятного способа. Это только побудит вас использовать, наконец, больше, чем вы действительно должны ...
Вместо определения struct Finally вы можете извлечь код очистки в функции класса Task и использовать ScopeGuard Локи.
ScopeGuard guard = MakeGuard(&Task::cleanup, task);
См. Также этот Статья DrDobb и этот другая статья для получения дополнительной информации о ScopeGuards.
Следует опасаться одной детали: если сам код очистки выдает ошибку, использование ScopeGuard молча отбрасывает сгенерированное исключение (что, безусловно, разумно, учитывая обработку исключений во время уничтожения в C++) - первый пример операции завершится, а второй вызовет ошибку. новое исключение из кода очистки вместо исходного исключения, если таковое имеется
Как говорили другие, «решение» - это лучшее разделение проблем. В вашем случае, почему переменная задачи не может позаботиться об очистке после себя? Если необходимо выполнить какую-либо очистку, то это должен быть не указатель, а объект RAII.
void foo() {
// Task* task;
ScopedTask task; // Some type which internally stores a Task*, but also contains a destructor for RAII cleanup
while (task = nextTask()) {
task->status = running;
// ...code that might throw an exception...
}
}
Умные указатели могут быть тем, что вам нужно в этом случае (boost :: shared_ptr удалит указатель по умолчанию, но вместо этого вы можете указать пользовательские функции удаления, которые могут вместо этого выполнять произвольные операции очистки. Для RAII на указателях это обычно то, что вы хочу.
Проблема не в отсутствии ключевого слова finally, а в том, что вы используете необработанные указатели, которые не могут реализовать RAII.
Но обычно каждый тип должен уметь убирать за собой. Не после каждого объекта, который находился в области видимости, когда было сгенерировано исключение (что в конечном итоге и произошло, и что вы пытались сделать), а сразу после него. И если каждый объект делает это, то вам вообще не нужна большая всеобъемлющая функция «очистка после каждого объекта в области видимости».
удалил мой комментарий, так как мой пример сокета был meh :) Я думаю, что согласен, есть несколько случаев, когда, наконец, можно использовать. но все равно было бы неплохо иметь / смоделировать :)
Это такой уродливый способ сделать это: (вы пришли с Java?)
Прочтите, пожалуйста, эту статью:
Поддерживает ли C++ блоки «finally»? (И что это за RAII, о котором я все время слышу?)
Это объясняет, почему, наконец, такая уродливая концепция и почему RIAA намного элегантнее.
Я перешел на C++ из Delphi, поэтому я знаю, о чем говорю. Я НЕНАВИЖУ наконец !!! Это уродливый. Я действительно не думаю, что С ++ наконец-то пропал.
Обычно я использую что-то вроде этого:
class Runner {
private:
Task & task;
State oldstate;
public:
Runner (Task &t, State newstate) : task(t), oldstate(t.status);
{
task.status = newstate;
};
~Runner()
{
task.status = oldstate;
};
};
void foo()
{
Task* task;
while (task = nextTask())
{
Runner r(*task, running);
// ...code that might throw an exception...
}
}
Это уродливо. Вы должны создать RunObject или что-то в этом роде !!!