Как подавить создание объекта исключения (.net)?

Question

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

Другими словами, можно ли создать исключение, но объект исключения не может быть создан?

Пример - Простой пример использования System.Net.Sockets.Socket

 Socket acceptingSocket;
acceptingSocket.Blocking = false;

while(condition)
{
    try
    {
        Socket acceptedSocket = acceptingSocket.Accept(); //(i)
        doWork(acceptedSocket);
    }
    catch{}
}

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

с использованием этой реализации кода - будет ли создан объект SocketException?

И если он создан - есть ли способ НЕ создать его?

Answer 1

Да, он будет создан. Нет, этого не избежать.

Answer 2

Это не связано, но важно, я думаю.

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

Answer 3

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

Также

catch(SocketException) {}

не

catch { } or catch(Exception) { }

:)

Answer 4

Объект исключения всегда создается при создании исключения. Все, что вы делаете, указываете, что вам все равно, какой тип исключения, и что вам не нужно ссылаться на него. doWork не будет вызываться, если исключение выдается acceptingSocket.Accept.

Ваш код эквивалентен:

catch(Exception) {}

Answer 5

Он всегда будет создан. AFAIK нет способа предотвратить создание объекта исключения ...

Answer 6

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

В вашем случае вы используете Socket. Существует множество возможных причин, по которым может генерироваться исключение SocketException ... например, при попытке чтения из закрытого сокета. Чтобы исключить исключение, вы должны убедиться, что сокет все еще открыт перед началом чтения. Это повлечет за собой дополнительные расходы на проверку состояния сокетов перед каждым чтением, но в долгосрочной перспективе вы, вероятно, сможете выполнить тысячи таких проверок, прежде чем достигнете уровня издержек, которые могут возникнуть при чтении из закрытого сокета и создании исключения.

В общем, выполнение таких проверок - просто хорошая практика программирования. Мы должны писать код, который максимально избегает исключительных случаев. Классическим примером этого является проверка параметров и других переменных на нулевое значение перед обращением к методам или свойствам к ним, что позволяет избежать страшного исключения NullReferenceException (исключение, которое в правильно написанном приложении НИКОГДА не должно быть выброшено.)

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

Answer 7

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

Старайтесь изо всех сил, чтобы избежать ненужных бросков / причинений.

Answer 8

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

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