Diciamo che scrivi un programma che, una volta avviato, legge il suo file di configurazione per sapere quali moduli avviare, ecc. Se quel file di configurazione è mancante, probabilmente verrà visualizzato un errore. Questa è una situazione importante che deve essere sempre gestita.
Ho letto una statistica una volta che diceva che circa il 70% del codice in un programma tipico è lì per trattare casi d'angolo (come controllare che il file non sia mancante, catturare un'eccezione, controllare che non divida per 0 , controlla che l'età di una persona sia un numero positivo ecc.).
Non credo che questo (il 70% di affermazione) sia molto accurato, ma ancora una volta, molto del codice che scrivo contiene un sacco di if s che controlla i parametri validi e cose del genere . Dubito di essere l'unico a farlo. Quindi quella statistica ha un po 'di verità.
Se una grande parte del codice di un programma è rappresentata da questi controlli, allora questi casi non dovrebbero essere rappresentati nei diagrammi UML? (come diagrammi di sequenza, ecc.). Non ricordo se ho mai visto cose del genere.
Devo includerli nei miei diagrammi? Questo illuminerà o disturberà / confonderà un altro programmatore che guarda quei diagrammi? I diagrammi sarebbero diventati troppo grandi per questo?