Utilizzando "intercettare le eccezioni" per migliorare la leggibilità, buona o cattiva?

Nella sezione Quando usare l'eccezione in The Pragmatic Programmer , il libro scrive che invece di:

retcode = OK;
     if (socket.read(name) != OK) {
      retcode = BAD_READ;
    }
     else {
      processName(name);
       if (socket.read(address) != OK) {
        retcode = BAD_READ;
      }
       else {
        processAddress(address);
         if (socket.read(telNo) != OK) {
          retcode = BAD_READ;
        }
         else {
          //  etc, etc...
        }
      }
    }
     return retcode;

, preferiscono:

 retcode = OK;
     try {
      socket.read(name);
      process(name);
      socket.read(address);
      processAddress(address);
      socket.read(telNo);
      //  etc, etc...
    }
     catch (IOException e) {
      retcode = BAD_READ;
      Logger.log( "Error reading individual: " + e.getMessage());
    }
     return retcode;

semplicemente perché sembra più ordinato. Sono tutto per il codice più ordinato, tuttavia non è inutile catturare le eccezioni un collo di bottiglia delle prestazioni?

Posso capire che dovremmo rinunciare all'ottimizzazione minuscola per il codice più ordinato (almeno il 99% delle volte), tuttavia da quello che so, la cattura delle eccezioni appartiene alla classe di codice che ha un notevole ritardo nel runtime. Quindi mi chiedevo qual è la giustificazione che il secondo pezzo di codice è preferito rispetto al primo codice?

O meglio, quale codice preferiresti?

Le eccezioni sono in genere più lente solo se effettivamente lanciate. Di solito, le eccezioni in situazioni come questa sono rare, quindi non è qualcosa di cui dovresti preoccuparti. Dovresti davvero preoccuparti dell'esecuzione delle eccezioni se si verificano continuamente e quindi sono un fattore significativo.

Il secondo codice è migliore perché è molto più facile seguire la logica. La gestione degli errori è ben localizzata. L'unica obiezione è che se si utilizzano le eccezioni, utilizzare le eccezioni. Non catturare le eccezioni e quindi restituire un codice di errore.

Bene, come si suol dire, le eccezioni dovrebbero gestire casi eccezionali , e dato che si tratta di un caso eccezionale (vale a dire qualcosa che accade poco e molto in mezzo) direi che questo vale anche qui.

Inoltre, vorrei consigliare contro cose micro-ottimizzazione, come questo. Concentrati maggiormente sulla leggibilità del codice , poiché passerai molto più tempo a leggere il codice che a scrivere un nuovo codice.

Per assicurarti davvero che si tratti di un collo di bottiglia nelle prestazioni, fai un po 'di profilazione e analizza e focalizza le attività più critiche sulla base di tale analisi.

Posso capire che dovremmo rinunciare all'ottimizzazione minuscola per il codice più ordinato (almeno il 99% delle volte), tuttavia da quello che so, la cattura delle eccezioni appartiene alla classe di codice che ha un notevole ritardo nel runtime.

Da dove lo sai? Come si definisce "notevole ritardo"?

Questo è esattamente il tipo di mito prestazionale vago (e completamente sbagliato) che porta a inutili ottimizzazioni premature.

Generare e catturare un'eccezione può essere lento rispetto all'aggiunta di due numeri, ma è completamente insignificante rispetto alla lettura dei dati da un socket. Probabilmente potresti lanciare e catturare mille eccezioni nello stesso tempo in cui hai letto un singolo pacchetto di rete. E non stiamo parlando di migliaia di eccezioni qui, solo una singola.

Sono d'accordo con le risposte che hai già ottenuto dicendo che questo è un caso eccezionale, quindi è ragionevole usare la gestione delle eccezioni.

Affrontando le tue prestazioni in modo più diretto, penso che tu debba mantenere un senso di scala sulle cose. Lanciare / catturare un'eccezione in queste circostanze è probabile che prenda uno dell'ordine di un microsecondo. Come va il controllo del flusso, è lento - molte volte più lento delle normali ifaffermazioni, nessuna domanda al riguardo.

Allo stesso tempo, tieni presente che quello che stai facendo qui è leggere i dati da una rete. A 10 megabit al secondo (lento per una rete locale, ma abbastanza veloce come vanno le connessioni Internet), è nello stesso ordine del tempo di lettura di un byte di informazioni.

Ovviamente, quel sovraccarico si verifica solo quando si lancia effettivamente anche l'eccezione - quando non viene generato, di solito c'è poco o nessun sovraccarico (almeno da quello che ho visto, il sovraccarico più significativo non proviene dal gestione delle eccezioni stessa, come dall'aggiunta di più potenziali flussi di controllo, rendendo il codice più difficile da ottimizzare anche per il compilatore).

In questo caso, quando viene generata un'eccezione, i dati di scrittura nel registro. Data la natura della registrazione, è molto probabile che svuoti quell'output non appena lo scrivi (per assicurarti che non vada perso). Scrivere su disco è (di nuovo) un'operazione piuttosto lenta - è necessario un SSD di classe enterprise abbastanza veloce per arrivare anche nell'intervallo di decine di migliaia di IOP / secondo. Un disco utilizzato per la registrazione potrebbe essere facilmente limitato a qualcosa come centinaia di IOP / secondo.

In conclusione: ci sono casi in cui l'overhead di gestione delle eccezioni può essere significativo, ma quasi sicuramente non è uno di questi.