Foutafhandeling (TRY – IF ERROR)

ps: Lijst van foutmeldingen gambas2 zijn hier nog terug te vinden:
http://files.allbasic.info/Gambas/help/help/error.html

Gambas heeft de TRY – IF ERROR combinatie.
Als de kans groot is dat zich een fout voordoet kan je de lijn beginnen met TRY. Als zich dan een fout voordoet crasht de applicatie niet, maar wordt akte genomen van de fout en loopt de applicatie door. Om waarschijnlijk verder toch in de problemen te komen?
Daarom is er de tweede stap: IF ERROR …
Deze instructie zet je na de lijn die begint met TRY.
Als er een fout is opgetreden, wordt de IF ERROR lijn uitgevoerd.

Dat is handig want je kan hier twee zaken mee doen:

  1. De foutmelding gaan ophalen, en er iets zinnigs mee doen, als loggen/opslaan, tonen, …
  2. De loop van het programma aanpassen aan het zich voordoen van de fout; kans geven om iets opnieuw te proberen, toestand van buttons / menu’s wijzigen zodat geen verdere akties genomen kunnen worden die de applicatie zouden doen crashen, een procedure starten om de fout effectief op te lossen, …

1. De foutmelding

De foutmelding zit in dat geval in Error.Text; je kan ze opvragen:

IF ERROR
  DEBUG Error.Text
ELSE
   ...
ENDIF

Terwijl je bezig bent met programmeren is het nuttig en nodig om de foutmeldingen te zien te krijgen. Als het programma crasht zie je ze. Soms wil je echter voortwerken aan een ander stuk van het programma, waarvoor deze fout niet belangrijk is. Je kan die dan “wegmoffelen” door voor de programmalijn die de fout levert, TRY te zetten. Het programma loopt na de fout door, maar: je krijgt de foutmelding niet meer te zien! Je ziet dus bv niet of ze verandert, zich niet meer zou voordoen, enz. Je vergeet ze misschien en dat levert laten een “bug” op.

Met deze DEBUG zie je ze tenminsten nog onderaan op je terminal-achtige venster in Gambas. Maar misschien is het beter ineens een procedure te maken om die fout ook in het lopende programma bij de gebruiker te gebruiken, want na compilatie zijn de DEBUG’s weg.

Eigenlijk is het minimum dat je ze opslaat in een tekstvariabele:

IF ERROR
  sLastError = Error.Text
...

Je kan dat lokaal doen, bv in elke module, Class, enz, lokaal een variabele maken om de fout op te slaan, en een procedure om ze op te vragen:

PRIVATE sLastError AS String
 
PUBLIC SUB getLastError() AS String
  RETURN sLastError
END


IF ERROR
  sLastError = Error.Text
...

De aanroepende code moet dan nog wel te weten komen dat er een fout was. Dat wordt meestal gedaan door
– een extreem andere waarde terug te geven als een waarde verwacht wordt (return value), bv 0 of -1.
– als geen return value nodig is, geef dan toch een TRUE als alles ok is, en FALSE terug als zich een fout voordeed.

In de aanroepende code:

IF module1.DoSomething(..)
  ...
ELSE
  Message.Error(module1.getLastError())
ENDIF

of, bv als je -1 als teken van fout gebruikt:

IF module1.CalcSomething(..) < 0
  Message.Error(module1.getLastError())
ELSE
  ...
ENDIF

Enkele ideeën:

  • Maak een procedure om de fouten op te vangen in je hoofdprogramma; bv doError(s AS String), die je de foutmelding laat weergeven in een speciaal foutmeldingsvenster in de app, en/of laat opslaan in een logbestand
  • Maak een class om de foutafhandeling te doen. Dan moet wel extra informatie door gegeven worden over waar de fout vandaan kwam.
This entry was posted in Uncategorized. Bookmark the permalink.