È una cattiva pratica lanciare un'eccezione arbitraria quando si imposta CancellationToken?

Question

È una cattiva pratica che le mie librerie interrompano i metodi lanciando qualcosa di diverso da un OperationCancelledException quando viene rilevato CancellationToken.IsCancelRequested?

Ad esempio:

async Task<TcpClient> ConnectAsync(string host, int port, CancellationToken ct) 
{ 
    var client = new TcpClient(); 
    try 
    { 
     using (ct.Register(client.Close, true)) 
     { 
      await client.ConnectAsync(host, port); 
     } 

     // Pick up strugglers here because ct.Register() may have hosed our client 
     ct.ThrowIfCancellationRequested(); 
    } 
    catch (Exception) 
    { 
     client.Close(); 
     throw; 
    } 

    return client; 
} 

All'annullamento, questo ha la possibilità di gettare ObjectDisposedException o NullReferenceException seconda dei tempi. (A causa TcpClient.ConnectAsync() può lanciare uno dei due quando TcpClient.Close() viene chiamato contemporaneamente.)

Ora, potrei risolvere questo modo:

async Task<TcpClient> ConnectAsync(string host, int port, CancellationToken ct) 
{ 
    var client = new TcpClient(); 
    try 
    { 
     using (ct.Register(client.Close, true)) 
     { 
      try 
      { 
       await client.ConnectAsync(host, port); 
      } 
      catch (Exception) 
      { 
       // These exceptions are likely because we closed the 
       // connection with ct.Register(). Convert them to 
       // OperationCancelledException if that's the case 
       ct.ThrowIfCancellationRequested(); 
       throw; 
      } 
     } 

     // Pick up strugglers here because ct.Register() may have hosed our client 
     ct.ThrowIfCancellationRequested(); 
    } 
    catch (Exception) 
    { 
     client.Close(); 
     throw; 
    } 

    return client; 
} 

E allo stesso modo in ogni strato della gerarchia di richiamo, se del caso:

async Task<TcpClient> ConnectSslStreamAsync(string host, int port, CancellationToken ct) 
{ 
    var client = await ConnectAsync(host, port, ct); 
    try 
    { 
     ct.ThrowIfCancellationRequested(); 

     var sslStream = new SslStream(client.getStream()); 
     using (ct.Register(sslStream.Close)) 
     { 
      try 
      { 
       await sslStream.AuthenticateAsClientAsync(...); 
      } 
      catch (Exception) 
      { 
       // These exceptions are likely because we closed the 
       // stream with ct.Register(). Convert them to 
       // OperationCancelledException if that's the case 
       ct.ThrowIfCancellationRequested(); 
       throw; 
      } 
     } 

     // Pick up strugglers here because ct.Register() may have hosed our stream 
     ct.ThrowIfCancellationRequested(); 
    } 
    catch (Exception) 
    { 
     client.Close(); 
     throw; 
    } 

    return client; 
} 

Ma questo aggiunge questo codice aggiuntivo quando, in realtà, tutto ciò che è richiesto è un controllo al livello più esterno. (Alla fonte di cancellazione.)

È una cattiva pratica lasciare volare queste eccezioni arbitrarie? O li stanno ignorando al più esterno chiamante convenzionale?

Answer 1

Si consiglia di inviare OperationCancelledException in caso di cancellazione. Quando i consumatori del tuo codice ottengono delle eccezioni, non avranno la minima idea se si trattasse effettivamente di una cancellazione o qualcos'altro.

Detto questo, se non si è in grado di lanciare OperationCancelledException a causa di registrazione vicino delegato, si potrebbe provare l'approccio fornito here dove potrete creare un'attività per la chiusura del tcpClient o ruscello e verificare quale compito ha completato prima e agire di conseguenza.