Set Error Capture (ON/OFF)

[andries]

Beste mensen,

 

ik heb een vraag over de "best practice" voor Set Error Capture (on) script stap.

 

Zet je dit het beste 1 maal aan het begin van je script, of gebruik je het enkel als je zeker weet dat je een fout gaat hebben binnen een bepaalde script stap, om die dan op te vangen, zoals:

 

...

 

Set Error Capture [ON]

Perform Find

If [Get ( LastError ) <> 0 ]

doe iets....

End If

Set Error Capture [OFF]

 

...

 

Tot nu toe zette ik deze script stap steeds in het begin van mijn script, maar ondertussen ben ik er achter gekomen dat enkel bij het programmeren in FileMaker dit zo wordt gebruikt. Zowel bij AppleScript als bij PHP (de enige twee andere talen die ik een beetje ken), gebruik je het opvangen van fouten enkel en alleen als dat ook echt je bedoeling is.

 

Ik denk ook niet dat hier een recht toe recht aan antwoord voor is, maar ik ben wel benieuwd naar andere gebruikers hun mening.

 

Groetjes

 

Andries

[JeanWM]

We moeten ervan uitgaan dat er binnen een computerprogramma altijd fouten kunnen voorkomen.

 

Binnen FileMaker is dat niet anders.

 

FileMaker zal altijd een hele reeks van fouten opvangen, onafgezien van de ‘stand’ van Set Error Capture().

Het enige wat je doet met Set Error Capture() is het al of niet tonen van een mogelijke fout aan de gebruiker.

Het niet tonen kun je enkel regelen binnen ScriptMaker. En als er een fout is opgetreden zal ScriptMaker dat doorgeven aan de Get(LastError) function.

 

Dus je stelling:

of gebruik je het enkel als je zeker weet dat je een fout gaat hebben binnen een bepaalde script stap, om die dan op te vangen

is niet helemaal juist.

 

Je wil weten ‘hoelang’ je ingestelde Set Error Capture() geldig blijft, of FileMaker een boodschap zal tonen of niet. Set Error Capture(On), geen boodschap, Set Error Capture(Off), wel een boodschap, terwijl een fout altijd opgevangen wordt door FileMaker.

 

Stel we hebben een reeks van scriptjes:

Script 01

......script steps...
Set Error Capture [On]
Perform Script ["02"]
Set Error Capture [Off]
Perform Script ["03"]
...some script steps...
Go to Layout [ original layout ]

 

Script 02

Print [Restore]

 

Script 03

...some other script steps...
Set Error Capture [On]
...various script steps...

 

Script 01 roept script 02 en script 03 aan.

 

Wat is de stand van Set Error Capture() op het ogenblik dat script 01 start ?

 

Off – omdat dat de default waarde is (op voorwaarde dat script 01 niet wordt aangeroepen door een ander script)

 

Loopt script 02 met Set Error Capture() On of Off ?

 

On – omdat bij het aanroepen van script 02, de Set Error Capture() op On stond in script 01.

Roep je daarentegen script 02 rechtsreeks aan, dan zal Set Error Capture() op Off staan.

 

Loopt script 03 met Set Error Capture() On of Off ?

 

Off – omdat net voor het aanroepen van script 03 de Set Error Capture() op Off werd gezet.

Maar tijdens het uitvoeren van het script zal het opnieuw op On gezet worden.

 

Is Set Error Capture() On of Off als script 01 verder loopt na het uitvoeren van script 03 ?

 

Je zou denken dat het Off is, maar het is On omdat Set Error Capture() op On werd gezet in script 03, net voor het terug naar script 01 springt.

 

Daaruit volgt dat het niet altijd aangewezen is om er zomaar vanuit te gaan dat Set Error Capture() op On of Off staat bij het begin van een script of bij het verder lopen (resume) van een script. En ook niet dat het niet zal veranderen tijdens het uitvoeren van verschillende sub-scripts.

 

Het is eigenlijk ook niet aangewezen een script te beginnen met Set Error Capture() op On.

Beter is die functie te plaatsen daar waar het nodig is, dat heet dan scriptdelen encapsulated maken.

In database development wordt het geheel Principle of Proximity genoemd.

 

Het is ook best Set Error Capture() terug op Off te zetten waar nodig, volgens het principe: Alles op zijn plaats en een plaats voor alles.

Dat is dan het vervolg van: als je iets wegneemt, plaats het terug, als je iets open zet, sluit het achteraf.

 

Hoe je nu best moet testen voor een Error is dan weer een ander verhaal.

 

Want je

If [Get ( LastError ) <> 0 ]

is niet helemaal veilig.

[andries]

Wel ik ben inderdaad teruggekomen van het idee om de script stap in het begin te zetten. Veel te veel problemen mee gehad en fouten die ik had willen zien hierdoor niet gezien. Veel tijd aan het debuggen verloren, en dingen die ik anders sneller had kunnen zien.

 

Het nadeel is: als je veel fouten moet opvangen zonder dat de gebruiker het ziet, moet je vaak het opvangen van fouten aan en uit zetten, wat het script aanzienlijk verlengd (en ik hou van korte scripts).

 

Wat is er fout met Get ( LastError ) <> 0 ? Is het beter om de foutcode te specifieren zoals Get ( LastError ) = 1 ?

[JeanWM]

Error trapping en Error Handling is tegelijkertijd simpel en complex.

Dus hou ik het kort voor nu.

 

Je moet een onderscheid maken tussen mogelijke fouten waar een gebruiker op kan reageren en fouten die jij, als developer, zou moeten weten.

 

Set Error Capture [ON] 
Perform Find 
If [Get ( LastError ) <> 0 ] 
doe iets.... 
End If

 

Is inderdaad een kort scriptje maar het is verre van efficient.

 

'Doe iets....' Doe wat ?

Je weet niet welke error code het mogelijk was. Wat ga je doen indien de code 721 is of 1200 ?

 

als je veel fouten moet opvangen......

 

wijst voor mij doorgaans op design flaws.

 

De error code heeft een vrij kort leven, net tot de volgende scriptstap wordt uitgevoerd.

 

Wat we doorgaans zien in een zoekscript:

 

Enter Find Mode [Pause]
Set Error Capture [On]
Perform Find [ ]
If [ Get (LastError) = 401 ]
 Show Custom Dialog ["Error"; "No whatever found"] 
 Show All Records
Else If [ Get (LastError) = 400 ]
 Show Custom Dialog ["Error"; "No search criteria provided"] 
End If

Dat lijkt goed, maar de kans bestaat dat er nooit op de 400 errorcode zal gereageerd worden.

 

Indien de gebruiker geen zoekcriteria ingeeft, bestaat de 400 code op het ogenblik dat de eerste If() wordt uitgevoerd.

De waarde wordt opnieuw op 0 gezet bij het uitvoeren van de tweede If(), die eigenlijk moet reageren op de 400 code, maar die is ondertussen al weg.....

 

Je vangt dus best een mogelijke errorcode op na iedere scriptstap, en schrijft die weg in een variable.

 

Voor gebruikersrelated errors behandel je de codes opgevangen in de variable, al of niet met een boodschap voor de gebruiker.

 

Voor developerrelated errors (alle andere errors die je niet specifiek behandeld) maak je dan best een ‘algemene’ errorcapture’ waarbij je een boodschap stuurt in de aard van;

 ‘Bel de developer (liefst in het midden van de nacht), en vertel hem welk nummertje je hier zieten wat je deed...’

 

Indien je Set Error Capture () op On zet bij het begin van je script, zullen mogelijke fouten nooit opduiken en kan een toepassing plots volledig stilvallen en niemand heeft ook maar een idee wat de mogelijke aanleiding zou kunnen geweest zijn.

 

Kan een simpele Go to Layout script stap zorgen voor problemen ?

Je zou denken van niet, maar indien je Set Error Capture op On staat en je vergeet b.v. om een correcte fieldvalidation te doen in je velddefinities (wat simpel neerkomt op het aanvinken van een veldje), kunnen er problemen opduiken.

De 507 code b.v. zal nooit verschijnen.

 

De regels die wij hanteren zijn dan ook:

Indien je Set Error Capture op On zet bij het begin van een script, moet je alle mogelijke fouten behandelen (niet aangewezen)

Zet Set Error Capture op On en Off waar en wanneer het nodig is

Gebruik de Get(LastError) na iedere scriptstap

Vang de mogelijk errors op in een variable

Behandel enkel specifieke errors (gebruikersrelated)

Gebruik een algemene test voor alle mogelijke andere niet behandelde errors.

 

Wij houden van efficiente scripts, zelfs als die wat langer zijn.....

[andries]

Dank voor het mooie antwoord.

 

Ik ben helemaal overtuigd. Het is idd een beetje meer werk om steeds de error capture aan en af te zetten, maar ik denk ook echt dat dit veel sneller fouten in het script naar boven brengt.

 

Hartelijk bedankt !