Избегание первых случайных сообщений об исключениях, когда исключение безопасно обрабатывается
следующий бит кода ловит исключение EOS
using (var reader = new BinaryReader(httpRequestBodyStream)) {
try {
while (true) {
bodyByteList.Add(reader.ReadByte());
}
} catch (EndOfStreamException) { }
}
Так почему я все еще получаю исключения первого шанса в моей консоли?
первое случайное исключение типа "System.IO.EndOfStreamException" произошло в mscorlib.dll
есть ли способ скрыть эти первые сообщения об исключениях?
9 ответов:
суть исключений "первого шанса" заключается в том, что вы видите их предварительный обработчик, чтобы вы могли остановиться на них во время отладки в момент броска. Исключение" второго шанса " -это исключение, которое не имеет соответствующего обработчика. Иногда вы хотите поймать исключения "первого шанса", потому что важно видеть, что происходит, когда его бросают, даже если кто-то его ловит.
тут не о чем беспокоиться. Это нормальное поведение.
чтобы избежать просмотра сообщений, щелкните правой кнопкой мыши на окне вывода и снимите флажок "сообщения об исключениях".
тем не менее, видеть их может быть приятно, если вам интересно знать, когда исключения генерируются без установки точек останова и перенастройки отладчика.
1)в Visual Studio можно изменить параметры способа обработки отладчиком исключений (перерывов).
перейти к отладке > исключения. (Обратите внимание, это может не быть в вашем меню в зависимости от вашей визуальной студии среде. Если не просто добавить его в меню с помощью меню Настройки.)
там вы представлены с диалогом исключений и когда разбить на них.
в строке "Common Language Runtime Exceptions" вы можете отменить выбор thrown (который затем следует прекратить беспокоить вас об исключениях первого шанса), и вы также можете отменить выбор User-unhandeled (что я бы не рекомендовал), если хотите.
2) сообщение, которое вы получаете, не должно быть в консоли, но должно появляться в окне "вывод" Visual Studio. Если это так, то я не нашел возможности удалить это, но он не появляется, если вы запускаете приложение без Visual Studio.
надеюсь, что это поможет.
В отличие от Java, исключения .NET довольно дороги с точки зрения вычислительной мощности, и обработанных исключений следует избегать в обычном и успешном пути выполнения.
вы не только избежите беспорядка в окне консоли, но и повысите производительность, и это сделает счетчики производительности, такие как исключения .NET CLR, более значимыми.
в этом примере вы бы использовали
while (reader.PeekChar() != -1) { bodyByteList.Add(reader.ReadByte()); }
У меня была эта проблема, и я не мог понять, где было брошено исключение. Поэтому мое решение состояло в том, чтобы позволить Visual Studio прекратить выполнение такого рода исключений.
- перейдите к "Debug / Exceptions"
- разверните дерево "исключения Общеязыковой среды выполнения".
- разверните ветку "система".
- прокрутите вниз до места, где находится" NullReferenceException", и проверьте установите флажок " бросить "и снимите флажок"обработано пользователем".
- отладка ваш проект.
Если вы хотите больше контролировать эти сообщения, Вы можете добавить обработчик:
Friend Sub AddTheHandler() AddHandler AppDomain.CurrentDomain.FirstChanceException, AddressOf FirstChanceExceptionHandler End Sub <Conditional("DEBUG")> Friend Sub FirstChanceExceptionHandler( source As Object, e As Runtime.ExceptionServices.FirstChanceExceptionEventArgs) ' Process first chance exception End Sub
Это позволяет вам заставить их замолчать, как упоминалось в других комментариях, но все же гарантирует, что вы можете быть в курсе их. Я считаю, что хорошо видеть, сколько я действительно бросаю, если я регистрирую сообщение и метку времени в текстовый файл.
на самом деле, если у вас много исключений в секунду, вы достигнете лучшей производительности, проверив reader.EndOfStream-значение.. Распечатка этих сообщений об исключениях невероятно медленная, и их скрытие в visual studio ничего не ускорит.
Я думаю, что поток бросает это исключение, поэтому ваша попытка сужается, чтобы поймать его.
добавьте еще несколько попыток поймать комбо вокруг разных областей, пока вы не поймаете его там, где он на самом деле бросается, но это, похоже, происходит либо за пределами вашего использования, так как объект stream не создается в области использования.