Quanto più costosa è un'eccezione che un valore di ritorno?

Question

E 'possibile modificare questo codice, con un valore di ritorno e un'eccezione:

public Foo Bar(Bar b) 
{ 
    if(b.Success) 
    { 
     return b; 
    } 
    else 
    { 
     throw n.Exception; 
    } 
} 

a questo, che genera eccezioni separate per il successo e il fallimento

public Foo Bar(Bar b) 
{ 
    throw b.Success ? new BarException(b) : new FooException(); 
} 

try 
{ 
    Bar(b) 
} 
catch(BarException bex) 
{ 
    return ex.Bar; 
} 
catch(FooException fex) 
{ 
    Console.WriteLine(fex.Message); 
} 

Answer 1

un'eccezione è sicuramente più costoso di restituire un valore. Ma in termini di costo grezzo è difficile dire quanto sia più costosa un'eccezione.

Quando si decide un valore di ritorno rispetto a un'eccezione, si dovrebbe sempre considerare la seguente regola.

Utilizzare solo eccezioni per i casi eccezionali

Non dovrebbero mai essere utilizzati per il flusso di controllo generale.

Answer 2

In alcune recenti analisi delle prestazioni di lavoro reali, abbiamo riscontrato che tonnellate di eccezioni su macchine di fascia bassa hanno avuto un effetto critico sulle prestazioni dell'applicazione, tanto che ci stiamo dedicando alcune settimane per passare e regolare il codice per non buttare così tanti

Quando dico un effetto critico, era nel campo da baseball di spiking dual core CPU fino al 95% sul nucleo singola CPU l'applicazione stava usando.

Answer 3

Ho problemi al momento di trovare tutti i documenti per sostenerlo, ma tenere a mente che quando si lancia un'eccezione, C# deve generare una traccia dello stack dal punto in cui è chiamato. Le tracce dello stack (e il riflesso in generale) sono tutt'altro che gratuiti.

Answer 4

si dovrebbe preferire eccezioni oltre i codici di errore, e per le condizioni di errore, ma non utilizzare le eccezioni per il normale flusso del programma.

Le eccezioni sono estremamente resistente rispetto al normale flusso di lavoro, ho visto un enorme ordine di grandezza in diminuzione le prestazioni delle applicazioni utilizzando un try-catch-block.

Answer 5

Utilizzando i rendimenti di errore sarà molto più costoso di eccezioni - non appena un pezzo di codice si dimentica di controllare il ritorno di errore, o non riesce a propagarla.

Eppure, essere sicuri di non utilizzare le eccezioni per il controllo di flusso - usarli solo per indicare che qualcosa è andato storto.

Answer 6

È possibile trovare un sacco di informazioni utili su questo le risposte a questa domanda, tra cui una risposta con il 45 up-voti How slow are .net exceptions?

Answer 7

Eccezione avere due costi: warm-up alla pagina nell'infrastruttura un'eccezione - se non nella memoria quindi nella cache della CPU - e per il costo per raccogliere lo stack delle eccezioni, cercare il gestore delle eccezioni, eventualmente richiamare i filtri delle eccezioni, sganciare lo stack, chiamare i blocchi di finalizzazione - tutte le operazioni che il runtime, in base alla progettazione, non ottimizza per.

Pertanto, la misurazione del costo di lancio delle eccezioni può essere fuorviante. Se scrivi un ciclo che gira in modo iterativo e ottiene un'eccezione, senza molto lavoro tra il sito di lancio e il sito di cattura, il costo non sarà così grande. Tuttavia, è perché sta ammortizzando il costo di riscaldamento delle eccezioni e questo costo è più difficile da misurare.

Certamente, le eccezioni non costano nulla come sembrano se l'esperienza principale è costituita dalle eccezioni generate dai programmi sotto il debugger. Ma costano, ed è consigliabile progettare le librerie in particolare in modo tale che le eccezioni possano essere evitate dove necessario per l'ottimizzazione.

Answer 8

Lanciare un'eccezione è un'operazione relativamente economica. Li sta intercettando con il costo a causa delle sequenze di stack che devono verificarsi per trovare i gestori catch, eseguire il codice nei catch catcher, trovare i blocchi finali, eseguire il codice nei blocchi finally e quindi tornare al caller originale.

È fortemente consigliato per non utilizzare eccezioni per il controllo del flusso. L'uso di codici di ritorno per indicare errori diventa costoso da un punto di vista del "tempo e materiali" in quanto alla fine incorrerà in costi di manutenzione.

Tutto questo a parte, i due esempi non corrispondono né sono nemmeno validi. Dal momento che sono di ritorno b, che è di tipo Bar, il vostro primo metodo dovrebbe probabilmente essere:

public Bar Foo(Bar b) 
{ 
    if(b.Success) 
    { 
     return b; 
    } 
    else 
    { 
     throw n.Exception; 
    } 
} 

che potrebbe essere riscritta come:

public Bar Foo(Bar b) 
{ 
    if (!b.Success) 
     throw n.Exception; 

    return b; 
} 

Answer 9

In generale ho evitato questo a causa della natura costoso di cogliere l'eccezione. Potrebbe non essere troppo male se non è qualcosa che accade spesso.

Tuttavia, perché non restituire null? Allora diventa questo:

public Foo Bar(Bar b) 
{ 
    if(b.Success) 
    { 
     return b; 
    } 
    else 
    { 
     return null; 
    } 
} 

E poi ogni volta che si chiama Bar() è sufficiente verificare che il valore restituito non è null prima di utilizzare il valore. Questa è un'operazione molto meno costosa. E immagino sia una buona pratica, perché questa è la tecnica che Microsoft ha utilizzato in tutte le funzioni incorporate in .NET.

Answer 10

usando il codice seguente, il test ha rivelato che la chiamata + tornare senza eccezioni sono voluti circa 1,6 microsecondi per ogni iterazione, mentre eccezioni (gettare più cattura) aggiunti i circa microsecondi ciascuno. (!)

public partial class Form1 : Form 
{ 
    public Form1() 
    { 
     InitializeComponent(); 
    } 

    private void button1_Click(object sender, EventArgs e) 
    { 
     DateTime start = DateTime.Now; 
     bool PreCheck = chkPrecheck.Checked; 
     bool NoThrow = chkNoThrow.Checked; 
     int divisor = (chkZero.Checked ? 0 : 1); 
     int Iterations = Convert.ToInt32(txtIterations.Text); 
     int i = 0; 
     ExceptionTest x = new ExceptionTest(); 
     int r = -2; 
     int stat = 0; 

     for(i=0; i < Iterations; i++) 
     { 
      try 
      { 
       r = x.TryDivide(divisor, PreCheck, NoThrow); 
      } 
      catch 
      { 
       stat = -3; 
      } 

     } 

     DateTime stop = DateTime.Now; 
     TimeSpan elapsed = stop - start; 
     txtTime.Text = elapsed.TotalMilliseconds.ToString(); 

     txtReturn.Text = r.ToString(); 
     txtStatus.Text = stat.ToString(); 

    } 
} 



class ExceptionTest 
{ 
    public int TryDivide(int quotient, bool precheck, bool nothrow) 
    { 
     if (precheck) 
     { 
      if (quotient == 0) 
      { 
       if (nothrow) 
       { 
        return -9; 
       } 
       else 
       { 
        throw new DivideByZeroException(); 
       } 

      } 
     } 
     else 
     { 
      try 
      { 
       int a; 
       a = 1/quotient; 
       return a; 
      } 
      catch 
      { 
       if (nothrow) 
       { 
        return -9; 
       } 
       else 
       { 
        throw; 
       } 
      } 
     } 
     return -1; 
    } 
} 

Quindi sì, le eccezioni sono MOLTO costoso.

E prima che qualcuno dice che, YES, ho provato questo uscita modalità e non solo Debug modalità. Prova tu stesso il codice e vedi se ottieni risultati significativamente diversi.

Answer 11

Ho visto molti sistemi diversi in cui le eccezioni erano considerate un'indicazione di un problema software e significa anche fornire informazioni sugli eventi che portano ad esso. Questo è sempre pesante sul sistema. Esistevano tuttavia sistemi in cui l'eccezione non era eccezionale in quanto il linguaggio stesso utilizzava metodi uguali o simili per tornare dalla routine ecc. Quindi si riduce a come le eccezioni sono incorporate nel linguaggio e nel sistema. Ho effettuato le mie misurazioni in java e in un sistema proprietario su cui lavoro in questo momento e i risultati erano come previsto - eccezionali, le eccezioni erano (20-25)% più costose.

Questa non deve essere la regola. Mi chiedo ad esempio come si poggia Python su questo. Non eseguo più lo sviluppo di python, quindi non ho intenzione di indagare.

Come una prova aneddotica forse interessante, prendere questo: nel sistema proprietario ho lavorato su alcuni anni indietro un uso non intelligente delle eccezioni per le violazioni del protocollo ha portato a problemi gravi e interruzione di uno dei nostri sistemi di produzione. Sono state utilizzate eccezioni per indicare campi obbligatori mancanti o corrotti in un messaggio ricevuto dall'esterno. Tutto andò bene fino a quando un giorno di sole una compagnia meno esperta produsse un nodo che, una volta messo in funzione, causò molti problemi. Le eccezioni dovevano essere rimosse poiché non siamo riusciti a far fronte anche a un livello basso di segnalazione da nodo difettoso. La colpa era in effetti anche dalla nostra parte - invece di seguire le specifiche del protocollo che descrivevano cosa fare con i messaggi formattati in modo errato (ignorare e superare il contatore degli errori di segnalazione) abbiamo cercato di rilevare e correggere l'errore del software nel nodo esterno. Se le eccezioni fossero meno costose, questo non sarebbe un grosso problema.

Infatti durante i test di sicurezza in questi giorni ho sempre un TC o pochi che fanno esattamente questo - generano un volume elevato di situazioni di violazione del protocollo. Se gli sviluppatori utilizzano eccezioni per gestirli, allora il sistema può essere messo in ginocchio abbastanza facilmente. Quando questa volta fallisce, inizierò a misurare di nuovo la differenza ....