with run net iscancellationrequested example detener cancellationtoken c# .net task-parallel-library task cancellation-token

run - kill task c#



¿Captar TaskCanceledException y comprobar Task.Canceled es una buena idea? (1)

En el marco de .Net en sí mismo, cuando pasa un CancellationToken como parámetro, recibirá una TaskCanceledException . No iría en contra de eso y crearía mi propio patrón de diseño porque las personas que están familiarizadas con .Net estarán familiarizadas con su código.

Mi guía es la siguiente: la que cancela el token es la que debe manejar la TaskCanceledException , por lo que si está utilizando un TaskCanceledException CancellationToken dentro de su método por sus propios motivos, siga adelante y use un bloque try-catch . Pero si obtiene el token como parámetro, deje que se lance la excepción .

Hay algunas personas en mi equipo que realmente aman la codificación con Task asíncronas. Y a veces les gusta usar los parámetros de CancellationToken .

Lo que no estoy seguro es si deberíamos, como equipo, usar este estilo de código (A):

async Task<someObject> DoStuff(CancellationToken t) { while (!t.IsCanceled) { try { Task.Delay(5000, t); } catch (AggregateException e) // or is it TaskCanceledException or OperationCanceledException? I don''t know? :) { } // poll something, return someObject, or null } return null; }

Obviamente, esto significa que la persona que llama probablemente debe verificar el token de cancelación para determinar si debe continuar procesando y es posible que tenga que manejar retornos nulos:

var retVal = await DoStuff(token); if (token.IsCanceled) { ... }

Sin embargo, si adoptamos un segundo estilo de código (B) que se basa en la excepción TaskCanceledException:

async Task<someObject> DoStuff(CancellationToken t) { while(true) { Task.Delay(5000, t); // poll something, return someObject, or null } }

El código de implementación es definitivamente más simple, y la persona que llama tiene la opción de manejar la excepción o no, según corresponda ... pero no puedo evitar preocuparme de que las personas que llaman puedan olvidar que TaskCanceledException es algo de lo que tienen que preocuparse y los procesos pueden fallar como resultado de no captar estas excepciones (en subprocesos de primer plano o de fondo).

Entonces, mi pregunta, demasiado optimista, es: ¿cuál crees que es el mejor estilo que todos deberían usar siempre y por qué? :)