ARK>>Непонятно. Это все не нужно. GetIter не должен завершаться с ошибкой.

for (Iter i : data)
{
    X x;
    if (i.Get(x))
    {
        ...
    }
}
if (data.IteratorCorrupted)
{
    ...
}

Because that error right there? No compiler error, no warning, you lose. You just have to be trained well enough to watch for them and prevent them. Very insidious bugs if you don't know what you're doing. One of the design philosophies of C++ is speed over safety. The runtime check that would lead iterator invalidation to an exception instead of unspecified behavior is too expensive, in the view of C++ language designers.

However, consider what happens when there are two different errors thrown in the same function:

class exception1 {};
class exception2 {};

try {
    ...
    if (condition1)
        throw my_exception1 ();
    ...
    if (condition2)
        throw my_exception2 ();
    ...
}
catch (my_exception1 &e) {
    handle_exception1 ();
}
catch (my_exception2 &e) {
    handle_exception2 ();
}

Compare that to its C equivalent:

...
if (condition1)
   handle_exception1 ();
...
if (condition2)
   handle_exception2 ();
...

It's far more readable and — as a bonus — compiler is likely to produce more efficient code.

EP>>И далее всё в таком духе

With C, the raising of the error and handling it are tightly couped and reside at the same place in the source code. This makes it easy to understand what happens if error happens:

int rc = fx ();
if (rc != 0)
    handle_error ();

With C++ you just throw the error. What happens then is not at all obvious:

int rc = fx ();
if (rc != 0)
    throw std::exception ();

The problem with that is that you have no idea of who and where is going to handle the exception.

CConnection * pConnection = null;
try 
{
  auto tmp = new CConnection(...);
  tmp.setProxy(...); 
  tmp.attachCertStore(...);
  pConnection = tmp;
} catch(...)
{
   // оппа! 
}

A>    error = sAIPanelFlyoutMenu->AppendItem(fPanelFlyoutMenu, 1, ai::UnicodeString("First Item"));
A>    error = sAIPanelFlyoutMenu->AppendItem(fPanelFlyoutMenu, 3, ai::UnicodeString("Third Item"));
A>    error = sAIPanelFlyoutMenu->InsertItem(fPanelFlyoutMenu, 3, 2, ai::UnicodeString("Second Item"));
A>    error = sAIPanelFlyoutMenu->InsertSeparator(fPanelFlyoutMenu, 3, 5);
A>    error = sAIPanelFlyoutMenu->AppendItem(fPanelFlyoutMenu, 4, ai::UnicodeString("Fourth Item"));
A>

%% Для варианта 1 и 2 ниже
%% нам нужен список элементов и функция, их добавляющая

list_of_items() ->
  ["First Item", "Third Item", separator, "Fourth Item"].

add_to_menu(Item) ->
  try
    fly_out_menu:append_item(panel_flyout_menu, Item)
  catch
    _:Reason -> {error, Reason}
  end.

%% ------------------------
%% Вариант 1
%% лопатим вручную
safe_add([], Errors) ->
  case Errors of
    [] -> ok;
    _ -> %% обработали ошибки, если надо
  end;
safe_add([Item|Rest], Errors) ->
  case add_to_menu(Item) of
    ok -> safe_add(Rest, Errors);
    {error, Reason} = safe_add(Rest, [Reason | Errors])
  end.

%% и дальше в коде где-то

safe_add(list_of_items()).

%% ------------------------
%% Вариант 2
%% foldl

safe_add(Item, Errors) ->
  case add_to_menu(Item) of
    ok -> Errors;
    {error, Reason} -> [Reason | Errors]
  end.

%% где-то в коде
  case lists:foldl(fun safe_add/2, [], list_of_items()) of
    [] -> ok;
    Errors -> %% обрабатываем все ошибки
  end.

%% ------------------------
%% Вариант 3
%% Один в один код из Адоба

adobe_style_adъ() ->
 % игнорируем ошибки
 catch fly_out_menu:append_item(panel_flyout_menu, "First Item"),
 catch fly_out_menu:append_item(panel_flyout_menu, "Third Item"),
 catch fly_out_menu:append_item(panel_flyout_menu, "Second Item"),
 catch fly_out_menu:append_item(panel_flyout_menu, separator),
 
 % не игнорируем ошибки
 fly_out_menu:append_item(panel_flyout_menu, "First Item").

%% где-то дальше в коде
try 
  adobe_style_adъ()
catch 
  _:Reason -> %обработали ошибку

Solution 3: The Real Approach

"Who said memory's going to exhaust? There's half a gig in this box!"

"Even if memory does exhaust, the paging system will slow the program down to a crawl way before the program crashes."

"The database folks said AddFriend cannot possibly fail. They're using XYZ and TZN!"

"It's not worth the trouble. We'll think of it at a later review."

  class Test
  {
    private MyItem[] _myArray;

    protected abstract void ProcessInternal(MyItem item);

    public void Process()
    {
      foreach (var item in _myArray)
      {
         ProcessInternal(item);   // throws Exception
      }

      // здесь _myArray оказался в неизвестно каком состоянии
    }

    error = sAIPanelFlyoutMenu->AppendItem(fPanelFlyoutMenu, 1, ai::UnicodeString("First Item"));
    error = sAIPanelFlyoutMenu->AppendItem(fPanelFlyoutMenu, 3, ai::UnicodeString("Third Item"));
    error = sAIPanelFlyoutMenu->InsertItem(fPanelFlyoutMenu, 3, 2, ai::UnicodeString("Second Item"));
    error = sAIPanelFlyoutMenu->InsertSeparator(fPanelFlyoutMenu, 3, 5);
    error = sAIPanelFlyoutMenu->AppendItem(fPanelFlyoutMenu, 4, ai::UnicodeString("Fourth Item"));

class Frobber
{
private:
    int m_NumberOfFrobs;
    FrobManager m_FrobManager;

public:

    void Frob()
    {
        m_NumberOfFrobs++;

        m_FrobManager.HandleFrob(new FrobObject());
    }
};

Really easy:
— Recognizing that error-code-based code is badly-written.
— Recognizing the difference between bad error-code-based code and not-bad error-code-based code.

Hard:
— Recognizing that error-code-base code is not badly-written.

Really hard:
— Recognizing that exception-based code is badly-written.
— Recognizing that exception-based code is not badly-written.
— Recognizing the difference between bad exception-based code and not-bad exception-based code.

ARK>>  class Test
ARK>>  {
ARK>>    private MyItem[] _myArray;

ARK>>    protected abstract void ProcessInternal(MyItem item);

ARK>>    public int  Process()
ARK>>    {
ARK>>      foreach (var item in _myArray)
ARK>>      {
ARK>>         if (ProcessInternal(item) != ERR_OK) return -1;   // error!
ARK>>      }

ARK>>      // здесь _myArray оказался в неизвестно каком состоянии
ARK>>    }
ARK>>

MTD>Отличный пример

  class Test
  {
    private MyItem[] _myArray;

    protected abstract void ProcessInternal(MyItem item) throws Error;  // видим возможность вылета и можем найти по Ctrl-F

    public void Process() throws Error    // видим возможность вылета и можем найти по Ctrl-F
    {
      foreach (var item in _myArray)
      {
         try!(ProcessInternal(item));           // видим возможность вылета и можем найти по Ctrl-F
      }

      // здесь _myArray оказался в неизвестно каком состоянии
    }

F>> Но вообще-то в исходном примере была простая лямбда.

TReply SyncRequest<TRequest, TReply>(TRequest request);

void PostAsync<TMessage>(TMessage request);

#define SUCCESS(x) if (!(x)) goto error;

Erlang: message passing, task failure, linked task failure, lightweight concurrency

        static int Main(string[] args)
        {
            var fileNames = new string[] { "header.js", "library.core.js",  "library.ext.js", "footer.js" };
            try
            {
                var content = fileNames
                    .Select(x => "// " + x + "\n" + File.ReadAllText(x) + "\n") // лямбда - тот самый код
                    .Aggregate((current, next) => current + next);
                return 0;
            }
            catch (Exception ex) // а тут нам вообще пофиг, что упало, но должно быть записано в лог, да ещё со стек-трейсом, что бы было понятно, кто виноват
            {
                Console.WriteLine("Error! {0}", ex.Message);
                return 1;
            }
        }

• запас карман не тяготит;
  
• лишний член — жопе непонятка.