Сильный метод гарантии, вызывающий сильные методы гарантии

Question

Когда у меня есть метод, который вызывает набор методов, которые обеспечивают надежную гарантию, у меня часто возникает проблема с откатом изменений, чтобы также иметь сильный метод гарантии. Давайте используем пример:

// Would like this to offer strong guarantee 
void MacroMethod() throw(...) 
{ 
    int i = 0; 
    try 
    { 
    for(i = 0; i < 100; ++i) 
     SetMethod(i); // this might throw 
    } 
    catch(const std::exception& _e) 
    { 
    // Undo changes that were done 
    for(int j = i; j >= 0; --j) 
     UnsetMethod(j); // this might throw 
    throw; 
    } 
} 

// Offers strong guarantee 
void SetMethod(int i) throw(...) 
{ 
    // Does a change on member i 
} 

// Offers strong guarantee 
void UnsetMethod() throw(...) 
{ 
    // Undoes a change on member i 
} 

Очевидно, что UnsetMethod может выбрасывать. В этом случае мой MacroMathod() предлагает только базовую гарантию. Тем не менее, я сделал все, что мог, чтобы предложить надежную гарантию, но я не могу быть абсолютно уверен, что мой UnsetMethod() не будет бросать. Вот мои вопросы:

1. Должен ли я попытаться предложить сильную гарантию в этом случае?
2. Должен ли я документировать свой MacroMethod() как имеющий базовую или сильную гарантию? Даже если это очень маловероятно, UnsetMethod будет бросать?
3. Можете ли вы увидеть способ сделать этот метод действительно надежной гарантией?
4. Возможно, мне следовало бы поставить вызов UnsetMethod() в попытке, но это кажется довольно тяжелым, и что мне делать в catch?

Спасибо!

Answer 1

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

Этот метод имеет то преимущество, что вам не нужны никакие try...catch -блоки в вашем коде, а также код очистки. Если выбрано исключение, измененная копия отбрасывается во время разворачивания стека, и оригинал вообще не был изменен.

Answer 2

Если важная важная гарантия важна для MacroMethod(), я бы пересмотрел UnsetMethod(), чтобы ничего не бросить, если можно. Конечно, как это можно сделать, зависит от того, что вы делаете.

Вы используете UnsetMethod() для очистки после отказа от SetMethod(). Если UnsetMethod() не удается очистить, что вы можете сделать по этому поводу? Это та же самая причина, почему бросание исключений из деструкторов чрезвычайно опасно.

Answer 3

1. Нет, вы не можете вообще с кодом, который вы указали. Однако, в зависимости от вашей проблемы, возможно, вы можете сделать копию данных, выполнить SetMethod на этой копии и затем поменять представление. Это обеспечивает надежную гарантию, но опять же зависит от проблемы.
2. Вы можете документировать: Сильная гарантия, если UnsetMethod не выбрасывает, в противном случае. На самом деле это объясняет, почему сказано, что деструкторы не должны бросать. Фактически любые операции отмены не должны бросаться.
3. Да, см. 1.
4. Нет, это не имеет никакого смысла.

Answer 4

Фундаментально, что вам нужно сделать в функции, которые требуют метательных функций работа на временную копию данных, пока все, возможно, метательной подфункции закончила, то swap (который не должен бросить) временный значения в «реальную» структуру.

Некоторого иллюстративный psudocode:

void MacroMethod() throw(...) 
{ 
    int i = 0; 
    MyValues working_copy[100] = *this; //obviously this is psudocode as I don't know your real code 
    for(i = 0; i < 100; ++i) 
    working_vopy[i].SetMethod(i); // if this throws the exception will propogate out, and no changes will be made 
    swap(*this, working_copy); // this must not throw 
}