c ++ попробуй поймать практики

Question

Это считается хорошей практикой программирования на C ++:

try {
// some code

}
catch(someException) {
// do something
}
catch (...) 
{

// left empty   <-- Good Practice???
} 

Answer 1

Нет! Это ужасная практика!

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

Если вы catch (...), вы абсолютно не представляете, какое исключение было сгенерировано, и, следовательно, вы не можете знать, безопасно ли продолжать работать.

Answer 2

хорошая практика это просто:

try {
// some code

}
catch( const someException & e) {
// do something
}

Потому что вы знаете, какое исключение (я) вы хотите поймать.

catch (...) должен быть только в вашем main () и в точке входа потоков (никакие исключения не должны оставлять потоки), после, конечно, перехвата (const std :: exception & e).

Answer 3

Нет. Это не очень хорошая практика программирования на C ++ или на любом другом языке.

Бесшумные сбои плохи и рано или поздно вас укусят.

Если вы собираетесь catch (...) , по крайней мере , вы должны указать, что вы делаете это. Вам также может понадобиться delete некоторые объекты, если вы не используете RAII.

Answer 4

Ну, это зависит от вашего приложения и проблемы, которую вы пытаетесь решить. Но в общем случае не стоит проглатывать неизвестные исключения. По крайней мере, я бы что-нибудь записал.

Редактировать : как отметил Ноа Робертс, единственное время, когда это может быть разумной идеей, - это разрушитель. Важно подавлять исключения в деструкторах, иначе вы можете иметь несколько активных исключений. Это может произойти, например, если выдается исключение, и в результате разматывания стека вызывается какой-то деструктор. Если этот деструктор выдает исключение, у вас будет 2 активных исключения. Затем C ++ вызовет std :: terminate (), что по умолчанию завершит вашу программу. Вы можете установить обработчик для этого условия, но, вероятно, вы мало что можете сделать, кроме как записывать происходящее.

Тем не менее, даже в деструкторе, вы, вероятно, должны регистрировать что-то внутри catch (...). Однако, в зависимости от того, какой это деструктор, у вас может не быть доступных средств ведения журнала. Но в большинстве случаев вы все равно можете использовать std::cerr.

Answer 5

Употребление исключений - плохая идея.

По крайней мере, внедрите какое-то протоколирование для ваших исключений. Возможно, вы захотите перезапустить исключение с сообщением об ошибке, которое лучше описывает проблему.

Answer 6

Единственный раз, когда я могу подумать, где это может быть необходимо - хотя это еще не значит, что это хорошо - это деструктор. Деструкторы не могут бросать, или у вас будут гораздо худшие проблемы, чем могло бы быть в этом исключении (возможно, за исключением bad_alloc). Если вы ничего не можете с этим поделать, когда что-то выбрасывает, тогда ваш улов будет пустым. Вы не можете отбросить, так как вы находитесь в деструкторе ... это действительно все, что вы можете сделать в этой ситуации.

Тем не менее, утверждение там или что-то будет оправданным.

Конечно, другие упоминали темы. Я просто не делаю MT, поэтому я не знаю проблем там.

Answer 7

Как стандартная практика, это действительно плохая идея. Если вы начинаете глотать исключения, когда не знаете, что с ними делать, тогда вы. предотвращение их обработки в более подходящих местах вниз по стеку вызовов и b. давая возможность вашей программе продолжить работу в каком-то ошибочном состоянии.

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

Итог, если вы не можете определить последствия ловли - не ловите.

Answer 8

Это один из тех вопросов "это зависит". Если вы имеете дело с плохо документированной сторонней библиотекой, которая пошла дальше и определила свое собственное исключение, которое не наследуется от std :: exception, у вас может не быть другого выбора. Опять же, я бы оставил это только в отладочной части моего кода.

Answer 9

Никогда не говорите в абсолютах. Я бы сказал, что вы почти никогда не должны проглатывать исключение. Однако в моем коде есть место, где я сделал это, не беспокоя меня:

class _ACLASS dstream 
    : public ofstream
{
//...
    long GetSize (void);
//...
Protected:
    string CheckRotation(void);
//...
};

string dstream::CheckRotation(void)
{   
//...
        // rotate if they aren't the same (it's a new day)
        // or our current file size exceeds the limit.
        if (currDay != newDay || GetSize() > fileSizeLimit * ONE_MEGABYTE)
        {
//...             
            Purge(); // while all files are closed, look for purge opportunity
            clear();
            open(Destination);
//...
}

// Return current file size
long dstream::GetSize (void)
{
    long retval =0;
    try {  // PBI 1227 was caused by this not being trapped.
        retval = (long)tellp ();
    } catch (...) { 
        retval =0; 
    } // Swallow the exception if any

    return retval;
}

Здесь я просто пытаюсь определить, превысил ли мой файл журнала 1 Мбайт (или сколько М байтов разрешено fileSizeLimit), и если это так, повернуть журнал. Если я получу исключение здесь, я просто сообщу вызывающему о размере 0 байт, и вызывающий не решит повернуть журнал в это время. При следующем вызове он, скорее всего, получит правильный ответ и передаст его.

Полагаю, что если tellp () генерирует исключение при каждом вызове, мой журнал не будет вращаться до полуночи. Но я сомневаюсь, что это может случиться (и я никогда не видел это в поле)

Answer 10

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

Башак Билги