usuario - try catch c#
Evitar mensajes de excepción de primera oportunidad cuando la excepción se maneja con seguridad (9)
El siguiente bit de código capta la excepción de EOS
using (var reader = new BinaryReader(httpRequestBodyStream)) {
try {
while (true) {
bodyByteList.Add(reader.ReadByte());
}
} catch (EndOfStreamException) { }
}
Entonces, ¿por qué todavía recibo excepciones de primera oportunidad en mi consola?
Se produjo una primera excepción de tipo ''System.IO.EndOfStreamException'' en mscorlib.dll
¿Hay alguna manera de ocultar estos mensajes de excepción de primera oportunidad?
1) En Visual Studio puede cambiar la configuración de la forma en que el depurador maneja las excepciones (interrupciones).
Vaya a Depurar> Excepciones. (Tenga en cuenta que esto puede no estar en su menú dependiendo de la configuración de su entorno de Visual Studio. Si no es así, agréguela a su menú usando el menú Personalizar).
Allí se le presenta un diálogo de excepciones y cuándo romper con ellas.
En la línea "Excepciones de Common Language Runtime" puede anular la selección de lanzamientos (lo que debería dejar de molestarlo con las excepciones de primera oportunidad) y también puede deseleccionar User-unhandeled (que no recomendaría) si lo desea.
2) El mensaje que está recibiendo no debe estar en la consola, sino que debe aparecer en la ventana ''Salida'' de Visual Studio. Si este es el caso, no he encontrado la posibilidad de eliminarlo, pero no aparece si ejecuta la aplicación sin Visual Studio.
Espero que ayude.
A diferencia de Java, las excepciones de .NET son bastante caras en términos de potencia de procesamiento, y las excepciones manejadas deben evitarse en la ruta de ejecución normal y exitosa.
No solo evitará el desorden en la ventana de la consola, sino que mejorará su rendimiento y hará que los contadores de rendimiento como .NET CLR Exceptions sean más significativos.
En este ejemplo usarías
while (reader.PeekChar() != -1)
{
bodyByteList.Add(reader.ReadByte());
}
Creo que la transmisión arroja esta excepción, por lo que su intento tiene un alcance estrecho para atraparlo.
Agregue algunos más combos de captura de prueba alrededor de los diferentes ámbitos hasta que lo atrape donde realmente está siendo arrojado, pero parece estar sucediendo ya sea en nuestro exterior de su uso, ya que el objeto de transmisión no se crea en el alcance del uso.
El objetivo de las excepciones de "primera oportunidad" es que las veas como pretrabajador para poder detenerse en ellas durante la depuración en el punto de lanzamiento. Una excepción de "segunda oportunidad" es aquella que no tiene un controlador apropiado. Algunas veces quiere atrapar excepciones de "primera oportunidad" porque es importante ver qué está sucediendo cuando se lanza, incluso si alguien lo está atrapando.
No hay nada de qué preocuparse. Este es un comportamiento normal.
En realidad, si se producen muchas excepciones por segundo, se obtendría un mejor rendimiento consultando el valor de reader.EndOfStream. La impresión de esos mensajes de excepción es increíblemente lenta y ocultarlos en Visual Studio no acelerará nada.
Para evitar ver los mensajes, haga clic derecho en la ventana de salida y desmarque "Mensajes de excepción".
Sin embargo, verlos suceder podría ser bueno, si le interesa saber cuándo se lanzan las excepciones sin establecer puntos de interrupción y reconfigurar el depurador.
Si desea más control sobre estos mensajes, puede agregar un controlador:
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
Esto le permite silenciarlos como se menciona en otros comentarios, pero aún así se asegura de que pueda conocerlos. Encuentro que es bueno ver cuántos estoy lanzando realmente si registro un mensaje y una marca de tiempo en un archivo de texto.
Tuve este problema y no pude averiguar dónde se lanzó la excepción. Así que mi solución fue permitir que Visual Studio dejara de ejecutar este tipo de excepción.
- Navegue a "Depurar / Excepciones"
- Expanda el árbol "Excepciones de Common Language Runtime".
- Expande la rama "Sistema".
- Desplácese hasta donde está "NullReferenceException", marque la casilla de verificación "throw" y desmarque la casilla "user-handled".
- Depure su proyecto.
en VB.NET:
<DebuggerHidden()> _
Public Function Write(ByVal Text As String) As Boolean
...