int modulo(int x, int m, int* result)
{
   int err_code = -1;// unknown error

   if(m > 0)
   {
      *result = x % m;

       err_code = 0;// ok. no error
   };

   return err_code;
}

int main(void)
{
   int x;
   int m;

   std::cin>>x;
   std::cin>>m;

   int res;

   const int err_code = modulo(x, m, &res);

   if(0 == err_code)
   {
     std::cout<<res;
   }
   else
  {
    std::cout<<"error";
  };
}

HRESULT

Во всех самолетах есть приборы, и самодельные самолеты — не исключение. Хотя в некоторых таких самолетах роль приборов играет компьютер с цветным графическим дисплеем (иногда даже «под» Windows NT), обычно ставят что-нибудь подешевле. Металлическая полоса, например, — простейший индикатор скорости. Чем быстрее Вы летите, тем сильнее она изгибается.

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

У компонентов СОМ нет приборов. Вместо шкал или лампочек для сообщений о текущем состоянии дел они используют HRESULT. QueryInterface вращает HRESULT. И, как мы увидим в оставшейся части книги, большинство функций интерфейсов СОМ также возвращает HRESULT. Xoтя из названия HRESULT можно было бы заключить, что это описатель (handle) результата, на самом деле это не так. HRESULT — это 32-разрядное значение, разделенное на три поля. Значения полей, составляющих HRESULT поясняет рис. 6-1. Название возникло по историческим причинам; расшифровывайте его как «вот результат» (here's the, result), а не «описатель результата» (handle of result).

Определенные системой значения HRESULT содержатся в заголовочном файле Win32 WINERROR.H. В начале файла расположены коды ошибок Win32, так что его нужно пролистать, чтобы добраться до HRESULT похож на код ошибки Win32, но это не одно и то же, и смешивать их не следует.

Старший бит HRESULT, как показано на рис. 6-1, отмечает, успешно или нет выполнена функция. Это позволяет определить много кодов возврата и для успеха, и для неудачи. Последние 16 битов содержат собственно код возврата. Остальные 15 битов содержат дополнительную информацию о типе и источнике кода ошибки.

В табл. 6-1 приведены наиболее часто используемые коды. По соглашению в названиях успешных кодов возврата содержится S_, а в названиях кодов ошибок — Е_.

Таблица 6-1. Распространенные значения HRESULT
Название Значение
S_OK Функция отработала успешно. В некоторых случаях этот код также означает, что функция возвращает логическую истину. Значение S_OK равно 0.
NOERROR Тоже,что S_ОК.
S_FALSE Функция отработала успешно и возвращает логическую ложь. Значение S_FALSE равно 1.
E_UNEXPECTED Неожиданная ошибка.
E_NOTIMPL Метод не реализован.
E_NOINTERFACE Компонент не поддерживает запрашиваемый интерфейс. Возвращается QueryInterface.
E_OUTOFMEMORY Компонент не может выделить требуемый объем памяти.
E_FAIL Ошибка по неуказанной причине.

Обратите внимание, что значение S_FALSE равно 1, а значение S_OK — 0. Это противоречит обычной практике программирования на C/C++, где 0 — это ложь, а не 0 — истина. Поэтому при использовании HRESULT обязательно явно сравнивайте коды возврата с S_FALSE или S_OK.

Пятнадцать битов — с 30-го по 16-й — содержат идентификатор средства (facility). Он указывает, какая часть операционной системы выдает данный код возврата.

LVV>А разве в С++ инструмент отсутствует?

Exceptions are, [...]

• Slow on the exceptional path
• Hopelessly serial
— Only one exception in flight
— Requires immediate, exclusive attention
— Dedicated control flow
• Associated only with root reasons, not goals
— “I/O error” doesn’t describe “saving
weight file”

• Common complaint: “Error codes are limited!
Exceptions are arbitrarily rich!”

1.1 Exception monad
[...]
There is an old dispute between C++ programmers on whether exceptions or error return codes are the right way. Also Niklaus Wirth considered exceptions to be the reincarnation of GOTO and thus omitted them in his languages. Haskell solves the problem a diplomatic way: Functions return error codes, but the handling of error codes does not uglify the calling code.

EP>Почему же во всех местах использования? Только в тех, где это критично.

EP>Если в каком-то месте критично чтобы вызов f() прошёл нормально, вернув нормальный результат, то и в случае с NaN'ами придётся городить проверки

if(1 == f())
{
   do_something();
}

__>if(1 == f())
__>{
__>   do_something();
__>}
__>

if(f() > 0)
   do_something();
else
   do_something2();

EP>>Почему же во всех местах использования? Только в тех, где это критично.

EP>>Если в каком-то месте критично чтобы вызов f() прошёл нормально, вернув нормальный результат, то и в случае с NaN'ами придётся городить проверки

__>да, но в том месте, где это некритично, проверки можно не ставить

__>но вам их обязательно надо ловить!

__>if(1 == f())
__>{
__>   do_something();
__>}
__>

try{ action1(); } catch(...){ /*ignore*/ }
try{ action2(); } catch(...){ /*ignore*/ }
try{ action3(); } catch(...){ /*ignore*/ }

// Building from exception
// © 2012- Andrei Alexandrescu. Do not redistribute. 23 / 54
template
<class E>
static Expected<T> fromException(const E& exception) {
  if (typeid(exception) != typeid(E)) {
    throw std::invalid_argument( "slicing detected");
  }
  return fromException(std::make_exception_ptr(exception));
}

166│   /// Obtain an exception_ptr pointing to a copy of the supplied object.
167│   template<typename _Ex>
168│     exception_ptr
169│     make_exception_ptr(_Ex __ex) _GLIBCXX_USE_NOEXCEPT
170│     {
171│ #if __cpp_exceptions
172│       try
173│         {
174├>          throw __ex;
175│         }
176│       catch(...)
177│         {
178│           return current_exception();
179│         }
180│ #else
181│       return exception_ptr();
182│ #endif
183│     }

takeOwnership( new A1, new A2 );

EP>Если же речь про strong guarantee, которую часто ассоциируют с транзакционностью — то её придётся "продумывать" в любом языке

<блок вычислений без контроля ошибок>

//--- начало контролируемой цепочки
extended<float> a_ex = <входные данные в контролируемую цепочку>

<цепочка вычислений, в том числе вида if(1 == a_ex){<bla-bla>}; поскольку сравнение с неопределенным значением - валидная и допускаемая компилятором  операция >

//-- завершение контролируемой цепочки
if(extended<float>::id_proper_value(a_ex))
{
    if(a_ex < 10){<do...>};
}
else
{
   cout<<"invalid result";
};

EP>>>Почему же во всех местах использования? Только в тех, где это критично.

EP>>>Если в каком-то месте критично чтобы вызов f() прошёл нормально, вернув нормальный результат, то и в случае с NaN'ами придётся городить проверки

__>>да, но в том месте, где это некритично, проверки можно не ставить

__>>но вам их обязательно надо ловить!

EP>Не вижу в этом проблемы — поставь catch наверху стэка

EP>Вообще-то наоборот — с исключениями мы имеем обычную логику не замусоренную проверками и обработками.

__>>if(1 == f())
__>>{
__>>   do_something();
__>>}
__>>

EP>try{ action1(); } catch(...){ /*ignore*/ }
EP>try{ action2(); } catch(...){ /*ignore*/ }
EP>try{ action3(); } catch(...){ /*ignore*/ }
EP>