Quando un crash è meglio di un check

Lavorando su codice esistente mi sono imbattuto in un passaggio simile al seguente, supponendo che MyControlName sia un elemento di UI indispensabile e sempre presente:

void Sample()
{
Control uiControl = FindControl("MyControlName");
if (uiControl != null)
{
DoSomething();
}
}

Se quell’elemento è sempre presente nella UI, perché fare il check? Solo per essere sicuri che nel codice scritto da noi non venga sollevata un eccezione?

Cosa succede se per qualche motivo il controllo non è più presente nella UI oppure il nome cambia?
Niente, assolutamente niente! Le operazioni che l’applicazione dovrebbe fare con MyControlName vengono silenziosamente ignorate (ed IMHO questi sono i bug più pericolosi).

Le strade sono due:

  1. si aggiunge un else in cui si avvisa il supporto che quel controllo non è reperibile (nobile, quanto forse di poca utilità pratica),
  2. si toglie il check e ci si imbatte nell’eccezione la prima volta che verrà eseguito il relativo test o comunque la prima volta che verrà utilizzato quel pezzo di codice (dal dev o dal tester, intendo, non dal cliente...).

Print | posted @ lunedì 22 febbraio 2010 11:20

Comments on this entry:

Gravatar # re: Quando un crash è meglio di un check
by fabrizio at 22/02/2010 12:25

Stesso discorso per le try catch dove nel catch viene bellamente ignorata l'eccezione: no log, no message, niente!
Comments have been closed on this topic.