Слишком много блоков Try Catch имеют низкую производительность? Любое альтернативное решение?

Question

Я разрабатывал веб-сайт с использованием c # с .net framework 4. Были реализованы концепции ОО. Каждый слой имеет несколько блоков Try Catch, используемых для обработки разных ошибок и возврата разных сообщений об ошибках. Я обнаружил, что при загрузке он замедляется, так как блок try catch становится все больше и больше. Интересно, это потому, что почему. Любое альтернативное решение? Поправь меня, если я ошибаюсь. Ценю за любой ответ.

Answer 1

Нет ничего плохого в использовании блоков try / catch. Они не влияют на производительность. что влияет на производительность - это ошибки?

см. Веб-сайт ниже, в частности:

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

http://msdn.microsoft.com/en-us/library/ms973839.aspx

Answer 2

Есть несколько хороших ссылок о try / catch и их стоимости. Microsoft говорит, что это может негативно повлиять на производительность.

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

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

Если это так, то я бы рассмотрел создание методов, которые явно возвращают ошибки как / когда необходимо и обрабатываютвместо этого.

Answer 3

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