Попытка C# {} выгода {}
привет и благодарит читать. Я - новичок в программировании и программировании гнезд и C#. в моем кодексе я пытаюсь поймать проблемы, чтобы обеспечить ошибку tolarence в моем приложении. следующее:
catch (ArgumentNullException e)
{
OnNetworkEvents eventArgs = new OnNetworkEvents("Network Unavailable", e.Message);
OnUpdateNetworkStatusMessage(this, eventArgs);
}
catch (EncoderFallbackException e)
{
OnNetworkEvents eventArgs = new OnNetworkEvents("Network Unavailable", e.Message);
OnUpdateNetworkStatusMessage(this, eventArgs);
}
catch (SocketException e)
{
OnNetworkEvents eventArgs = new OnNetworkEvents("Network Unavailable", e.Message);
OnUpdateNetworkStatusMessage(this, eventArgs);
}
catch (ArgumentOutOfRangeException e)
{
OnNetworkEvents eventArgs = new OnNetworkEvents("Network Unavailable", e.Message);
OnUpdateNetworkStatusMessage(this, eventArgs);
}
catch (ObjectDisposedException e)
{
OnNetworkEvents eventArgs = new OnNetworkEvents("Network Unavailable", e.Message);
OnUpdateNetworkStatusMessage(this, eventArgs);
}
я просто задавался вопросом, могу ли я заменить этот повторяющийся кодекс одним синглом:
catch (Exception e) { handle here}
это работало бы?
еще раз спасибо.
11 ответов
Нет, Никогда не ловить System.Exception . Я чувствую себя как сломанная запись сегодня, но я действительно не могу подчеркнуть этого достаточно. Вы не можете обрабатывать OutofMemoryException или AccessViolationException , так что не поймай его!
Что касается примерного кода, у меня сильные сомнения, что ArgumentNullexception или ArgumentOutofRange Исключение будет соответствовать ошибке сети. Если это делает, он, вероятно, означает, что компонент, который действительно должен , не должен ловить это исключение, нет.
«Устойчивость к неисправностям» не означает «ешьте все исключение, чтобы приложение не хватало» - значит, на самом деле знание того, что может пойти не так, и обрабатывать их правильно.
как общий ориентир Cav System.Exception . Это плохая идея и плохой кодовый запах, указывающий на неспособность понять цель исключения. Я считаю, что это результат убеждения Dev, что исключения - ошибка вместо кода, который срабатывает исключение.
Я вижу этот провал в производственном коде все время, и все неизменно маскирует реальные ошибки, так как действительные, и полезные исключения пойманы и проглатываются, оставляя приложение в плохом состоянии. Это делает это много Crackister, чтобы отслеживать корневую причину неудачи.
Уловляющие исключения, использующие метод, который вы использовали здесь, более или менее правильный способ сделать это. Существует несколько вещей, которые вы можете захотеть рассмотреть вопрос о улучшении, хотя:
, как правило, не лечит
ArcientNullexceptionилиArgumentOutofrangeexceptionкак сбой сети выполнения (если только это на самом деле). Скорее, следует учитывать логическую ошибку, которая заставляет вашу программу потерпеть неудачу как можно быстрее (так что вы можете проверить ее с отладчиком как можно ближе к точке отказа). Это часто означает не ловить ни одногоArgumentExceptionвообще.Рассмотрите возможность изучения иерархии исключения, чтобы найти соответствующее базовое исключение, которое охватывает исключения, которые вы пытаетесь сообщить. E.G., (я не посмотрел на него), предположим, что три ваших исключения, которые вытекают из
SocketException. Вы можете сохранить некоторые печатать, ловивSocketExceptionвместо трех отдельных исключений. Однако только если вы сообщаете все исключения сокета. (Это в основном более дисциплинарная версия вашей оригинальной попытки просто пойматьисключение), потому что обе линии в каждом обработке исключения идентичны, вы можете создать функцию для выполнения этих двух строк Работайте в одной строке в обработчике . Типичные не повторяющиеся рефакторинг. Если вы хотите изменить то, как вы сообщаете о своем исключении, подумайте, насколько легче было бы изменить одну функцию, чем все эти индивидуальные обработчики.
Просто о каком-либо значительном вводе ввода / вывода (сеть и файл приходят) собирается повлечь за собой довольно значительную цепочку обработчиков исключений только потому, что есть так много, что может пойти не так. Увидев много ошибок, сообщающуюся вокруг ввода / вывода, которая может выйти из строя, не является анти-образцом, но это может быть хорошим запахом кода. Как сосновый свежий аромат или свежеиспеченный хлеб. :)
, который, безусловно, поймает все исключения, но это может быть плохой практикой. Есть некоторые исключения, которые будут скрыты или искажать, что сделает тестирование и отладки вашего приложения гораздо сложнее.
Как предложить все предыдущие комментарии, вы должны поймать все «Известен» исключения с исключением Специфический комфортный блок и другие неизвестные, или более соответствующие, все «непревзойденные» Исключения с CATS (исключение Ex) {...} или просто Catch {...}
Однако, как указано в вашем коде, вы обрабатываете все виды исключения так же. Таким образом, в этом конкретном случае выход (то, что вы звоните неисправности ), будут одинаковыми, но производительность улучшится (поскольку время выполнения не нужно сравнивать тип исключения с заданным списком типов).
Мораль этой истории: Используйте один общий попыток в этом конкретном случае. Но вообще избегайте такой привычки.
Это будет работать, но он также будет ловить «нулевые ссылки» исключения и любое другое случайное исключение, которое было брошено.
Да, это бы работа , но это не сделало бы то же самое, поскольку все исключения, и не только конкретные будут уловлены.
Это обычно не то, что вы хотите, поскольку общее правило - поймать только исключения, которые вы знаете, как обращаться. Существуют некоторые ситуации, когда вам понадобится такой улов, все, чтобы перенаправить исключение (например, наличие границ по нире Accross или в асинхронных вызовах) или в async-вызовах) или выполнять некоторые уборки, если что-то - что-то - идет не так твоя работа).
Это будет ловить все исключения, которые наследуют от класса исключения. Если они все обрабатываются так же, как вы можете сделать это, но вы не должны справиться с всеми исключениями, унаследованными от исключения так же.
Я на самом деле просто прочитал сообщение в блоге на эту очень тему этим утром.
Вы могли бы сделать что-то, как упомянуто в комментариях поста:
catch(Exception e){
if( e is ArgumentNullException
|| e is EncoderFallbackException
|| e is ...whatever
){
OnNetworkEvents eventArgs = new OnNetworkEvents("Network Unavailable", e.Message);
OnUpdateNetworkStatusMessage(this, eventArgs);
} else { throw; }
}
Вы могли бы, но потеряли бы гранулярность и возможность обрабатывать каждый вопрос по отдельности, что не является лучшей практикой. Обычно вы сначала обрабатываете различные типы исключений, точно так же, как и вы, а затем, если вам нужно что-то сделать с любыми необработанными исключениями, вы можете добавить в конце Exception Exception. Перебросьте его, как только закончите, чтобы сохранить трассировку стека и дать ему пузыриться.
Сохраните в конце то, что у вас есть, добавить базовый регистр:
catch (ArgumentNullException e) { ... }
catch (EncoderFallbackException e) { ... }
catch (SocketException e) { ... }
catch (ArgumentOutOfRangeException e) { ... }
catch (ObjectDisposedException e) { ... }
catch (Exception e)
{
// not handled by above exceptions, do something if needed
throw; // after doing what you need, re-throw it
}
Хотя вы можете это сделать, я бы посчитал это плохой практикой, а не тем, как вы захотите структурировать свой код.
В зависимости от исключения, вы можете захотеть сделать что-то другое. Недопустимый IP - это другая проблема, чем аппаратная ошибка и так далее. К тому же, некоторые ошибки вы можете захотеть уведомить UI через делегата или войти куда-нибудь, используя log4net.
Но это только я и я далек от эксперта - так что принимайте это как есть
.IMO:
Поймать Исключение было бы довольно похоже на наличие методов с параметрами, которые никогда не бывают более специфичными для класса, чем Object; Конечно, вы можете это сделать, но действительно ли это лучшее решение 9 из 10 раз?
Что вы должны подумать о том, чтобы упростить свой код, так это то, что исключения из правил поймать в самом высоком определении, которое имеет отношение к делу.
Например, в java я бы
try{...}
catch( IOException e ) {...}
поймал все исключения, связанные с IO.
Слишком много вещей, которые могут бросать слишком много различных типов исключений, обычно следует избегать использования catch-all, то есть Exception.