Dapper SqlException y excepción no observada

.net c# dapper task-parallel-library

Pregunta

Tengo un problema con el siguiente código cuando el procedimiento T-SQL genera un error (SQLException)

    var result = await conn.QueryMultipleAsync("Inventory.uspLoadItems", new
    {
        dbId = obj.myId,
    },
    commandType: CommandType.StoredProcedure);
    var items = await result.ReadAsync();
    var specificItems = MyCustomMapper.MapTo<MyItem>((dynamic)items);

Estoy usando Dapper versión 1.50.2.

El proceso se convierte en una excepción no observada.

Puedo seguir la excepción hasta el método del controlador WebApi. Pero cuando existe el método del controlador, otro subproceso (spawn e inacabado) continúa ejecutándose en var items = await items.ReadAsync(); incluso si la sesión de WebApi ha finalizado (¿GC recopilada?). (El texto se borró debido a una información errónea en la ventana Parallell Stack. La excepción falló en ReadAsync, no en QueryMultipleAsync y, por lo tanto , no continuó después de la excepción ). Parece un problema de enhebrado en Dapper, pero no estoy seguro.

ACTUALIZAR

Encontré el siguiente enlace en Microsoft Connect que parece estar muy relacionado con este tema. https://connect.microsoft.com/VisualStudio/feedback/details/2592987/sqldatareader-nextresultasync-causes-unobserved-task-exception-even-when-awaited

Entonces, para cualquier otra persona que experimente este comportamiento. Tendrás que esperar a la próxima actualización de .NET.

No es un problema Dapper, pero si Dapper-contributers pudiera encontrar una solución temporal, sería lindo :)

Por ahora, cambio todo mi ReadAsync a Read (sincrónico) para evitar este error SqlDataReader.

Respuesta popular

otro subproceso (spawn e inacabado) continúa ejecutándose en var items = aguarda items.ReadAsync ();

Parece que la función en la que existe todo este código se ejecuta de forma asíncrona y no se espera ni se sincroniza de ninguna otra forma. La solicitud principal finaliza mientras esta función aún se está ejecutando (esto no es una suposición, su observación demuestra que el código se ejecuta después de que el controlador haya terminado). Entonces, si este código falla, la excepción no se observa.

Sería una solución incorrecta ignorar las excepciones no observadas. Recomiendo hacer eso de todos modos, pero la solución correcta es esperar la tarea de la que este código es parte.

Dado que es su código el que aún se está ejecutando, no es un error de framework. El error al que se vinculó podría provocar que el código de la infraestructura se ejecute más tarde y sin que se observe, pero no causará declaraciones después de que espere que se ejecute (nuevamente).



Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow
¿Es esto KB legal? Sí, aprende por qué
Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow
¿Es esto KB legal? Sí, aprende por qué