В случае FAILED делай return (это можно обернуть в макрос).
Очистку ресурсов делай в деструкторах.

День добрый.

Вот такой вопрос возник: есть кусок кода, который "в лоб" можно написать так

try {
 if (FAILED(Foo1())) throw hr;
 ...
 if (FAILED(Foo2())) throw hr;
 ...
} 
catch (...) {
  ShowErrorMessage (hr);
}

вот только использование try не желательно. Чем заменить.
Есть вариант так

HRESULT hr  = S_OK;
do {
  hr = Foo1(); 
  if (FAILED(hr)) break;
  ...
} while (false);

if (FAILED(hr)) ShowErrorMessage (hr);

А может есть иные варианты?

А почему использование исключений нежелательно?

Doc>вот только использование try не желательно. Чем заменить.
Doc>Есть вариант так
Doc>

Doc>HRESULT hr  = S_OK;
Doc>do {
Doc>  hr = Foo1(); 
Doc>  if (FAILED(hr)) break;
Doc>  ...
Doc>} while (false);

Doc>if (FAILED(hr)) ShowErrorMessage (hr);
Doc>

Doc>А может есть иные варианты?

Если если надо прыгать на точку выхода из функции, с очисткой, то лучше всего goto.
Метка всего одна, не запутаешься:

Resource* res1 = NULL;
Resource* res2 = NULL;

hr = Foo1(); 
if (FAILED(hr)) goto CLEANUP;

res1 = ...;

hr = Bar2();
if (FAILED(hr)) goto CLEANUP;

res2 = ...;

CLEANUP:

if (res1)
  FreeResource(res1);

if (res2)
  FreeResource(res2);

Проверку можно макросом сделать, чтобы код не засорять проверочной логикой.
В Мозилловском коде так сделано, там макрос NS_ENSURE(..), как-то так, правда, они по нему сразу из функции выходят, у них все почти ресурсы автоматически удаляются в деструкторах.

Ещё читал, что так же (goto CLEANUP) в линуксовском ядре сделано.
Это удобно очень, код не засоряет тривиальной проверочной логикой и левыми циклами, а поскольку метка всего одна, ничего страшного в goto нет.
Правда, не уверен, вызываются ли деструкторы локальных объектов, если прыгаем из вложенного блока в конец внешнего.
А вариант с циклом не подойдёт, если уже есть внешний цикл — break не метку, как в C#, в C++ вроде нет.

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

_>А почему использование исключений нежелательно?

1) Программа небольшая. Везде уже сделана струкрутрная обработка ошибок.
Ради одной функции затевать обработку на эксепшенах — нет смысла.

2) Не люблю накладных расходы (даже если они копеечные), которых можно избежать.

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

E>А вариант с циклом не подойдёт, если уже есть внешний цикл — break не метку, как в C#, в C++ вроде нет.

В моем блоке нет внутренних циклов. Так что тут нет проблем.

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

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

_>>А почему использование исключений нежелательно?

Doc>1) Программа небольшая. Везде уже сделана струкрутрная обработка ошибок.
Doc>Ради одной функции затевать обработку на эксепшенах — нет смысла.

Doc>2) Не люблю накладных расходы (даже если они копеечные), которых можно избежать.

они нанокопеечные

КЛ>они нанокопеечные
Смотря как реализован механизм исключений. Я бы не стал называть копеечным лишний вызов ядра, а везь throw в VC так и делает

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

L>В случае FAILED делай return (это можно обернуть в макрос).
L>Очистку ресурсов делай в деструкторах.

Это заставит разбивать каждую функцию на несколько мелких. Иначе как при return выводить сообщения.

Здравствуйте, Константин Л., Вы писали:

КЛ>они нанокопеечные

Спорить не буду (в смысле нет такой цели). Но если все уже сделано структурно, то пихать эксшепшн еще и не красиво. IMHO идеология должна быть едина в программе (особенно если она среднего или малого размера и пишется небольшой командой или вообще одним человеком).

L>>В случае FAILED делай return (это можно обернуть в макрос).
L>>Очистку ресурсов делай в деструкторах.

Doc>Это заставит разбивать каждую функцию на несколько мелких. Иначе как при return выводить сообщения.

Через деструктор обьекта, создаваемый на стеке. В принципе, тоже можно завернуть в макрос.

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

Doc>Здравствуйте, Константин Л., Вы писали:

КЛ>>они нанокопеечные

Doc>Спорить не буду (в смысле нет такой цели). Но если все уже сделано структурно, то пихать эксшепшн еще и не красиво. IMHO идеология должна быть едина в программе (особенно если она среднего или малого размера и пишется небольшой командой или вообще одним человеком).

если проект имеет свойство расширяться, то добавление обработки исключений будет дальновидным решением.