Существует ли преимущество для ПРОСТО “броска” в выгоде?

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

Так обычно не хорошая практика, чтобы поймать и повторно бросить исключение.

Причины ловли и замены это за другим исключением могло бы быть

• Вход
• Скрывающаяся уязвимая информация от вызывающей стороны (Stacktrace, детали исключения)

, И для отладки Вас мог бы хотеть изменить Ваше "Повреждение, когда исключение: "-Обработчик (Нажатие Ctrl+Alt+e) значение, "брошенное" на выбранные Исключения CLR.

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

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

На практике моя мысль, если Вы не намереваетесь обработать ошибку, не ловите ее.

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

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

Вы делаете не , нуждаются в пункте выгоды для ловли исключений в отладчике Visual Studio. Выберите Debug > Исключения и выбор, какие исключения Вы хотите поймать, все они при необходимости.

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

объяснение я видел переносящиеся исключения с новыми, вместо того, чтобы просто позволить им пузырь стек, то, что исключения должны быть на том же symantic уровне как методы, из которых они происходят. Если я называю AuthenticateUser, я не хочу видеть исключение SQL. Вместо этого я должен видеть некоторое исключение, имя которого говорит мне, что задача аутентификации не могла быть выполнена. Если я рою во внутренние исключения этого исключения, я мог бы затем найти исключение SQL. Лично, я все еще взвешиваю за и против выполнения этого.

Да, это удобно для помещения точки останова в выгоде.

альтернативный и более чистый путь состоит в том, чтобы установить контрольные точки в конструкторе объекта, который Вы бросаете. Вы видите состояние программы в точке ближе к источнику ошибки.

С тех пор существует нулевая обработка ошибок, эта выгода бесполезна. Если бы там регистрировался или некоторая очистка, сделанная уверенный, но в этой ситуации я избавился бы от попытки/выгоды.

Это может также быть полезно, если необходимо осмотреть что-то об исключении, и сделать что-то для одного обстоятельства или бросить его для других обстоятельств. Например, если необходимо осмотреть код ошибки в SQLException. Можно выполнить определенные действия, если код ошибки является тем, Вы готовы обработать. Для других можно просто "бросить" его так, отслеживание стека сохраняется, как упомянуто выше.