Der er rigtigt mange måder at lave fejlhåndtering på, og skrevet tons af bøger og teorier om hvornår det er godt at bruge try-catch, null-returnering som identifier, eller state koder og meget meget mere.
Nogle mener at try-catch er effektivt fordi du kan pakke exceptions ind i hinanden, og andre mener det er skidt fordi det er "dyrt" at lave det.
Jeg personligt har fundet et system jeg synes fungerer rigtigt godt, som involverer man altid har et ResponseObject til ALLE metoder. Det vil sige du har et base object med response kodes, succes-property, eller hvad du nu ønsker at have til at identificere dine kald.
Personligt bruger jeg en Succes-property, og en ErrorCode-property som kan sættes til en enumerator. Hvis man så sender denne enumerator til et fejlmodul finder den teksten for den så du kan returnere den.
Så skal man selvfølgelig lave forskellige objekter alt efter hvad man ønsker at returnere, så du får et object af den type med tilbage du ønsker. Skal det være et array, en boolean, en liste, et objekt eller hvad du nu har behov for.
Fordelen for mig er helt klart at du kan ændre dit base-response object som du ønsker - så du kan have fx i dit fejl modul have en GetSystemErrorMessage (fx en MSSQL fejl), og en GetUserErrorMessage (fx "Der skete en fejl da regninger skulle hentes. Kontakt venligst West Inc. på 87 56 43 21").
Således kan du skrive en sigende besked i din log når der sker en fejl, hvor du kan se der ikke er forbindelse til databasen, og til brugeren kan du give en passende fejlbesked de forstår som ikke er så teknisk.
Der kan jo være mange forskellige typer fejl med filen er låst, du har ikke adgang til netværksdrevet, og meget meget mere - og dermed nemmere at skelne imellem hvad skal du gøre nu - skal du forsøge igen, eller ved du at der ikke er mere at gøre? Det er også nemmere at fortælle brugeren noget mere sigende.
Ingen kommentarer:
Send en kommentar
Kan du lide mit indlæg, har en kommentar, forslag eller andet på hjerte så skriv venligst