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

S>catch (...) нужен для того, что если даже в подсистеме компиляции глюк, и она выбрасывает какое-либо левое исключение, то это не приведет к падению, например, всего сервера приложений, в котором она используется. Это позволяет четко специфицировать, что данная подсистема выбрасывает только CompileException и ничего больше. Так будет более удобно работать с ней на более высоких уровнях приложения.

Как минимум в данном примере мы теряем первопричину исключения. От того, что оно теперь какого-то одного типа ни жарко ни холодно. Всегда можно (и нужно) поставить на самом высоком уровне catch(...), чтобы избежать падений сервера приложения. Но давить первопричину исключения — это ИМХО даже хуже чем вообще его не обрабатывать.

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

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

S>>catch (...) нужен для того, что если даже в подсистеме компиляции глюк, и она выбрасывает какое-либо левое исключение, то это не приведет к падению, например, всего сервера приложений, в котором она используется. Это позволяет четко специфицировать, что данная подсистема выбрасывает только CompileException и ничего больше. Так будет более удобно работать с ней на более высоких уровнях приложения.

IT>Как минимум в данном примере мы теряем первопричину исключения. От того, что оно теперь какого-то одного типа ни жарко ни холодно. Всегда можно (и нужно) поставить на самом высоком уровне catch(...), чтобы избежать падений сервера приложения. Но давить первопричину исключения — это ИМХО даже хуже чем вообще его не обрабатывать.

С теоритической точки зрения все это так. Но в C++ проблема, зачастую, бывает в использовании сторонней библиотеки, которая использует исключения, не производные от std::exception. И еще хорошо, если есть своя вершина иерархии классов исключений, чтобы можно было писать так:

try
    {
        ...
    }
catch( const std::exception & x )
    {
        ...
    }
catch( const some_another_exception_root & x )
    {
        ...
    }

Хуже, если таких some_another_exception_root-ов несколько. В таких сутациях catch(...), имхо, вполне допустим.

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

E>Хуже, если таких some_another_exception_root-ов несколько. В таких сутациях catch(...), имхо, вполне допустим.

Понятное дело допустим. Я о том, что перехват всех подряд исключений и замена их на свои — это не лучший вариант. Даже в .NET, где для этой цели есть InnerException. А уж в плюсах и подавно. В RFD я поддался на уговоры и сделал так же. Т.е. из RFD выходят только исключения RFD. Ничего хорошего из этого не вышло. Практической пользы мизер, неудобств масса.

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

IT>Как минимум в данном примере мы теряем первопричину исключения.

Первопричина таких исключений одна — ты где-то налажал в коде. Это на самом деле и есть логическая причина, т.е. причина, интересная пользователю данной подсистемы. Ее и надо показывать.

А если рассуждать по твоему, то следующий код тоже будет неправильным:

SQLStmt stmt = Conn.PrepareStmt("insert into UserTable values (:p0)");

try
{
    stmt.setStringParam(1, userName);
    stmt.execute();
}
catch (const SQLUniqueConstraintException &e)
{
    throw MyException("User already exist.");
}

В этом коде мы прячем первопричину, точно также, как и случае с моим предыдущим примером.


IT>От того, что оно теперь какого-то одного типа ни жарко ни холодно. Всегда можно (и нужно) поставить на самом высоком уровне catch(...), чтобы избежать падений сервера приложения.

От того, что подсистема выкидывает левые, неспецифицированные в ней исключения, становится очень "холодно". catch(...) на самом высоком уровне не всегда может помочь, например пакетное задание на компиляцию:

vector<string> fileNames = ...;
vector<string> errors;

for (size_t i = 0; i != fileNames.size(); i++)
{
    try
    {
        Compiler comp;
        comp.Compile(fileNames[i]);
    }
    catch (const CompileException &e)
    {
        errors[i] = e.getMessage();
    }
    errors[i] = ""; // Compilation ok.
}

Если, по каким-то причинам в процессе одной из компиляций вылезет левый ексепшен, то в случае catch(...) накроется только эта компиляция, а не все задание.

И, кстати говоря, от того что ты поставишь catch(...) на самом верхнем уровне, тебе будет точно также "ни жарко ни холодно", и ты точно также скроешь первопричину исключения.

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


IT> Т.е. из RFD выходят только исключения RFD. Ничего хорошего из этого не вышло. Практической пользы мизер, неудобств масса.
А конкретнее в чем выражаются неудобства, можно?

С уважением, Gleb.