I relation til mit indlæg om "exception håndtering" på Mød Microsoft den 20. og 21. oktober har jeg fået et spørgsmål om, hvordan jeg forholder mig til følgende artikel fra "Joel on Software": "Exceptions".

• Exceptions laver implicitte hop.
  
  Når en exception kastes sker der et hop i eksekveringen af applikationen - et hop der ikke (nødvendigvis) fremgår eksplicit af koden i en given procedure. Et eksempel på dette kunne være, at proc1 kalder proc2, som kalder proc3. Hvis der kastes en exception i proc3, som ikke fanges i proc2, vil der set fra proc2s synspunkt blive foretaget en return fra proc2 ved kald til proc3.



• Exceptions skaber for mange returns fra en procedure.
  
  Hvis en exception ikke fanges i en given procedure, vil der ske en umiddelbar return fra proceduren. Det betyder, at alle eksekverede statements, der kan kaste exceptions, i princippet vil kunne opføre sig som en return fra proceduren.

Jeg er ganske enig i Joels forudsætninger for vurdering af brugen af exceptions: At eksplicit kode er godt og at man bør begrænse mængden af returns fra en given procedure, men jeg er ikke enig i, at disse pointer skal føre til, at man slet ikke benytter exceptions.

Naturligvis kunne samtlige procedurer returnere en fejlkode (eller noget bedre: et fejlobjekt). Kaldsproceduren kunne så forholde sig til denne fejlkode og tage de nødvendige aktioner og forholdsregler. Gør en udvikler sig rigtigt meget umagen, vil det være muligt at lave applikationer, der aldrig fejler (med en exception). Desværre har historien med al tydelighed vist, at det er yderst sjældent, at en udvikler vitterligt håndterer alle situationer.

Essensen ved at benytte exceptions er, at opstår der en uforudset fejl (i en procedure) er man sikret, at proceduren meddeler dette til kaldsproceduren på en måde, så det ikke kan overses. Og hovedpræmissen for brugen af exceptions er, at man langt vil foretrække, at et program går ned frem for, at der eksekveres ”uforudset” kode: Naturligvis er det træls og ærgerligt, når en applikation går ned pga. en unhandled exception – men det er trods alt for intet at regne i forhold til de problemer, man kan få, hvis applikationen dag efter dag, år efter år producerer fejlagtige resultater.

At betragte exceptions på linje med simple hop (gotos) og returns, opfatter jeg som en overforsimpling af deres funktionalitet – og en tæt på blåøjet holdning til hvor grundigt og systematisk applikationer opbygges.

At benytte exceptions er på ingen måde en undskyldning for ikke at lave pæn kode. Er det overhovedet muligt at forudsige/gætte, hvilke fejl der kan opstå i et givet kodeelement, bør man naturligvis kode defensivt og eksplicit. Men når man så rent faktisk har gjort sit yderste i forhold til at udvise rettidig omhu, er det så også betryggende at vide, at skulle der opstå en uforudset fejl, vil systemet ikke blot køre videre, som om intet var hændt, men at det i stedet vil sige fra i en sådan grad, at det ikke kan ignoreres – ved at kaste en exception.

Selvom jeg ikke er enig med Joel i, at exceptions bør undgåes, betragter jeg det dog som et problem, at man ikke kan se, hvilke exceptions der kastes fra en given assembly (samt de assemblies der kaldes fra denne). Dette problem kunne evt. afhjælpes ved hjælp af et værktøj, der foretager statisk (kode)analyse af assemblyen (og dens refererede assemblies). Udskifter man en (direkte eller indirekte) refereret assembly, skal man ganske vist foretage en ny analyse (på samme måde som man altid bør gennemteste sit program forfra), men det kunne i det mindste give en vis sikkerhed for, at man har behandlet (eller i hvert fald overvejet, hvorvidt man ønsker at behandle) alle relevante exception.

På samme måde som det gælder for så mange andre mekanismer, bør exceptions bruges med god smag og uden, at det overdrives eller misbruges. Men brugt på den rette måde, mener jeg så også at exceptions kan hjælpe med til at ens applikationer opfører sig mere korrekt.