Где Вам нравится ловить исключения и почему?

Не ловите ничего, что Вы не готовы и способный обработать.

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

И необходимо сделать только одну из двух вещей: на самом деле сделайте что-то, чтобы решать/работать вокруг проблемы или повторно бросить более описательное исключение, которое имеет перехваченную исключительную ситуацию как innerException.

Править: Если Вам нужен a finally блок (например, выпускать что-то, что Вы выделили в своем коде) и у Вас ничего нет полезным, чтобы сделать за любыми исключениями, которые могли бы открыться, та же логика применяется: просто не обрабатывайте их. Вместо этого используйте a catch { throw; } повторно бросить исключение в более высокий уровень при сохранении всей информации об исключении в целости. (Или просто опустите блок выгоды, который я думаю/надеюсь, делает то же самое?)

Я пытаюсь поймать ТОЛЬКО те исключения, с которыми я могу иметь дело.

Я НЕНАВИЖУ код как это:

      String s="12";
      Integer i;
        try {
          i = Integer.parseInt(s);
        } catch(ParseException pe) {
          System.out.println("hihihihihihihi!!!);
        }

То, что я особенно ненавижу, - то, что то, что это обычно делает, должно прервать поток так или иначе, потому что три строки позже будет доступ ко мне, который предположит что я! = пустой указатель.

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

Мне жаль, что Java не вынудил меня поймать Исключения, что я не могу иметь дело с, так или иначе. Но то, что я могу сделать, является этим:

catch(Exception e) {
  throw new RuntimeException(e);
}

И я объявляю много "бросков" в моих функциональных определениях.

Я все еще мечтаю о дне, где Eclipse автоматически откроет Debugger в корректной строке, когда это получит неперехваченное исключение. В тот день мой метод откроет корректную строку.

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

Идея состоит в том, что я не хочу, чтобы ошибка была зарегистрирована или зарегистрирована. Я хочу зафиксированный.

Я всегда вставлял основную выгоду () как выгода последней инстанции:

int main( int argc, char** argv ) {
    try {
        Application application( argc, argv );
        return application.result();
    }
    catch ( const std::exception& exception ) {
        fprintf( stderr, "%s.\n", exception.what() );
    }
}

В C# и Java я предпочитаю не ловить исключения вообще. Если я не могу избежать его, я сразу повторно бросаю Исключение на этапе выполнения.

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

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

public void stuff() throws MyException
{
    try
    {
        tryStuff();
    }
    catch (SomeLibraryException e)
    {
        logger.log("Some message happened", e);
        throw new MyException(e);
    }
}

public void tryStuff() throws SomeLibraryException
{
   // Do things in here that could throw exceptions
}

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

void Controller::on_edit_entity( const Entity& entity ) {
    try {
        Command::ptr command = new EditEntityCommand( entity );
        push_command( command );
    }
    catch ( const std::exception& exception ) {
        fprintf( stderr, "%s.\n", exception.what() );
    }
}

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

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

Я только обработал бы исключение если:

• Я должен сделать некоторую очистку (как откат DB), в этом случае, я повторно повысил бы исключение после того, как очистка сделана.
• У меня есть еще некоторая информация для добавления к исключению.
• Мой метод может преуспеть, это - цель несмотря на исключение.

Два места:

• Во всех обработчиках событий
• Любое местоположение, где выгода может сделать что-то полезное, как дополнение исключение с информацией, которая будет полезна для отладки. Обычно новое исключение будет создано с этой информацией и выдано. Обратите внимание, что InnerException (или эквивалентный non-.NET) этого нового исключения должен быть установлен на то из исходного исключения, чтобы вещи как отслеживание стека были сохранены.