• Не стоит намеренно коверкать фамилию Страуструпа.
  
• С каких пор Страуструп — "автор по С"?
  
• Как Сишник связан с диаграммами классов и т.д.?
  
• Не стоит рисовать диаграммы только ради рисования. Это — средство, а не цель.

WH>>Плохой у тебя опыт и бедные твои заказчики.

WH>>В моей программе перехватываются все исключения(просто надо немного заботися о проектировании). Болие того для выброса исключений я использую пару трюков вобщем лог с исключениями содержит очень подробную информацию о том что (имя исключения), где (фаил, строка), почему(проваленое условие) и коментарии(часть контекста по усмотрению программиста). А если учесть что формат лога строго стандартизирован то для него можно написать смотрелку(что я и сделал).

HRESULT hr;
...
ATLASSERT( SUCCEEDED( hr = pObj->Play( taram param ) ) );
if(hr == S_FALSE) ...

SmartHRESULT hr;

...
hr = pObj->Play( taram param );
if(hr...)

HERE(hr) = pObj->Play( taram param );
if(hr...)

HRESULT hr; // глупый


HR_THROW_SUCCEEDED(hr) = pArray->Resize(n); // вероятно поймать E_OUTOFMEMORY или E_ABORT
if(hr == S_FALSE) // same size
  ...

HR_THROW_OK(hr) = CoCreateInstance(CLSID_TheParser, <.......>, (void**)pParser);
  // если обломились - значит криво зарегистрирован сервер

HR_ASSERT_OK(hr) = pParser->Parse("hello");

HR_ASSERT_OK_FAIL(hr) = pParser->Parse(str);
if(hr == E_FAIL) blablabla;

if (OK==f(x))
  if (OK==f2(x))
    if (OK==f3(x))
    else
  else
else

bool success;

try
  f(x)
  f2(x)
  f3(x)
catch

KK>if (OK==f(x))
KK>  if (OK==f2(x))
KK>    if (OK==f3(x))
KK>    else
KK>  else
KK>else  
KK>

inline bool Ok(ECODE e) { return e == OK; }
//....
  Ok(f(x)) &&
  Ok(f2(x)) &&
  Ok(f3(x));

try
{
...
   if ( F(...)==0 ) throw ex1 ;
....
}
catch ( ex1)
{

}

...
if ( F(...)==0 ) gote ex1 ;
...
ex1:...

WH>Да и проявлятся она будет после дождичка в четверг. Именно такие ошибки труднее всего поймать, а если у тебя рухнула программа то ты покрайней мере будешь знать что она есть. А если это произошло под отладчиком то еще будешь знать где именно.

try {
   .....
}
catch (CTheException ex) {
   .....
}

try {
   .....
}
catch (CTheException* pEx) {
   .....
}

try {
   .....
}
catch (CTheException& ex) {
   .....
}

struct E{int i; E(const E &){...}};

void low_level(){
  ...
  try{...}
  catch(E &e){
    ...
    e.i++; 
    raise e;//тоесть тут не произойдет копирование E?
    ...  
  }
  ...
}

void high_level{
  try{
   ...
   low_level();
   ... 
  }
  catch(const E &e){
    ...
  }
}

ssm>struct E{int i; E(const E &){...}};

ssm>void low_level(){
ssm>  ...
ssm>  try{...}
ssm>  catch(E &e){
ssm>    ...
ssm>    e.i++; 
ssm>    raise e;//тоесть тут не произойдет копирование E?
ssm>    ...  
ssm>  }
ssm>  ...
ssm>}

ssm>void high_level{
ssm>  try{
ssm>   ...
ssm>   low_level();
ssm>   ... 
ssm>  }
ssm>  catch(const E &e){
ssm>    ...
ssm>  }
ssm>}
ssm>

throw;

ssm>  try{...}
ssm>  catch(E &e){
ssm>    ...
ssm>    e.i++; 
ssm>    throw;//тоесть тут не произойдет копирование E?
ssm>    ...  
ssm>  }

ДН>не произойдет

try
{
  try
  {
    // ...
    CMyException e;
    e.set(1);
    throw e;
  }
  catch(CMyException e1)
  {
    e1.set(2); 
    throw;
  }
}
catch(CMyException& e2)
{
  // что здесь будет в e2 - 1 или 2 ?
}

15.1/4
...
The temporary persists as long as there is a handler being executed for that
exception. In particular, if a handler exits by executing a throw; statement, 
that passes control to another handler for the same exception, so the temporary remains.
...

КД>Короче, всякое бывает

catch(const exception& exc)
{
 throw exc;
}

КД>Стандарт, стандарт... пишем же на реализациях

КД>catch(const exception& exc)
КД>{
КД> throw exc;
КД>}
КД>

КД>Из-за этой хрени я начал подумывать — а почему в std::exception нет виртуального метода raise

15.1/3
A throw-expression initializes a temporary object, the type of which is determined by removing 
any toplevel cvqualifiers from the static type of the operand of throw...

catch(const exception& exc)
{
 throw;
}

15.1/4
The memory for the temporary copy of the exception being thrown is allocated in an unspecified way,
except as noted in 3.7.3.1. The temporary persists as long as there is a handler being executed for that
exception. In particular, if a handler exits by executing a throw; statement, that passes control 
to another handler for the same exception, so the temporary remains. When the last handler 
being executed for the exception exits by any means other than throw; the temporary object is 
destroyed and the implementation may deallocate the memory for the temporary object; 
any such deallocation is done in an unspecified way.
The destruction occurs immediately after the destruction of the object declared in the exceptiondeclaration
in the handler.