С++ попробовать методы catch

Ответ 1

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

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

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

Ответ 2

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

try {
// some code

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

Ответ 5

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

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

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

Ответ 6

Исключение исключений - плохая идея.

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

Ответ 7

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

Ответ 8

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

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

Нижняя строка, если вы не можете определить последствия улова - не поймайте.

Ответ 9

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

Башак Бильги

Ответ 10

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

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

string dstream::CheckRotation(void)
{   
//...
        // rotate if they aren't the same (it 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 Мбайт (или даже много M байтов, разрешенных файлом), и если это так, поверните журнал. Если я получаю исключение здесь, я просто буду сообщать размер байта 0 байта, и вызывающий абонент не будет выбирать, чтобы повернуть журнал в это время. При следующем вызове он, вероятно, получит правильный ответ и передаст это.

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