Следующий бит кода ловит исключение EOS
using (var reader = new BinaryReader(httpRequestBodyStream)) {
try {
while (true) {
bodyByteList.Add(reader.ReadByte());
}
} catch (EndOfStreamException) { }
}
Итак, почему я все еще получаю исключения из первого шанса в моей консоли?
Первое исключение исключения типа "System.IO.EndOfStreamException" произошло в mscorlib.dll
Есть ли способ скрыть эти сообщения об исключительных случайных исключениях?
Точка исключений "первого шанса" заключается в том, что вы видите их перед обработчиком, чтобы вы могли остановиться на них во время отладки в момент метания. Исключением "второй шанс" является тот, у которого нет соответствующего обработчика. Иногда вы хотите поймать исключения "первого шанса", потому что важно видеть, что происходит при его броске, даже если кто-то его ловит.
Там нечего беспокоиться. Это нормальное поведение.
Чтобы избежать просмотра сообщений, щелкните правой кнопкой мыши на окне вывода и снимите флажок "Исключительные сообщения".
Однако, видение их может быть приятным, если вам интересно знать, когда исключаются исключения, не устанавливая точки останова и не перенастраивая отладчик.
1) В Visual Studio вы можете изменить настройки для того, как отладчик обрабатывает (прерывает) исключения.
Перейдите в раздел "Отладка" > "Исключения". (Обратите внимание, что это может не быть в вашем меню в зависимости от настройки среды Visual Studio. Если вы не просто добавите его в свое меню в меню "Настроить".)
Там вы получите диалог с исключениями и когда их разбить.
В строке "Исключения общего времени выполнения языка" вы можете отменить выбор (что должно перестать беспокоить вас об исключениях из первого шанса), и вы также можете отменить выбор пользователя User-unhandeled (который я бы не рекомендовал), если хотите.
2) Сообщение, которое вы получаете, не должно находиться в консоли, но должно появляться в окне "Выход" Visual Studio. Если это так, то я не нашел возможности удалить его, но он не появляется, если вы запускаете приложение без Visual Studio.
Надеюсь, что это поможет.
В отличие от Java, исключения .NET довольно дороги с точки зрения мощности обработки, а обработанные исключения следует избегать в нормальном и успешном пути выполнения.
Вы не только избежите беспорядка в окне консоли, но и улучшите свою производительность, и сделайте счетчики производительности, такие как .NET CLR Exceptions, более значимыми.
В этом примере вы использовали бы
while (reader.PeekChar() != -1)
{
bodyByteList.Add(reader.ReadByte());
}
У меня была эта проблема, и я не мог понять, где было исключено исключение. Поэтому мое решение состояло в том, чтобы позволить Visual Studio прекратить выполнение этого исключения.
Если вы хотите больше контролировать эти сообщения, вы можете добавить обработчик:
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-значение. Распечатка этих сообщений об исключениях невероятно медленна, и их скрытие в визуальной студии не ускорит ничего.
в VB.NET:
<DebuggerHidden()> _
Public Function Write(ByVal Text As String) As Boolean
...
Я думаю, что поток выбрасывает это исключение, поэтому ваша попытка ограничена, чтобы ее поймать.
Добавьте еще несколько попыток catch combos вокруг разных областей, пока вы не поймаете их там, где их действительно бросают, но, похоже, это происходит либо вне нашего использования, поскольку объект потока не создается в области использования.