Martijn Linsen heeft het Perpetuum Mobile van de software-ontwikkeling bedacht, was de eerste gedachtengang van Dick Streefland na het lezen van het artikel ‘Foutvrij programmeren’. Hij heeft echter zijn bedenkingen.
Bij het lezen van het artikel (Computable van 2004-03-12) kon ik een glimlach niet onderdrukken. De auteur beweert hier daadwerkelijk het Perpetuum Mobile van de software ontwikkeling te hebben uitgevonden: de magische formule voor foutvrije programma’s.
De eerste techniek, ACP, vervangt functionele interfaces door het modificeren van een gedeeld object. Dat kan in sommige situaties misschien handig zijn, maar ik zie niet in hoe dit de software foutvrij zou kunnen maken. De kans op fouten neemt eerder toe, omdat de interface van de functie minder strak is, en niet meer uit het prototype is af te leiden.
De Siblr-techniek (de b van ‘business’ is raadselachtig) is niets anders dan een ingewikkelde manier om een ‘goto’ statement na te bootsen. Het komt op mij over als een krampachtige manier om het gebruik van ‘goto’ te vermijden. Ook hier is onduidelijk hoe een beetje syntactische suiker een programma foutvrij kan maken.
Naschrift
ACP stuurt inderdaad aan op één gedeeld object, waarin alle belangrijke waardes zitten. Dat heeft misschien zijn nadelen (ik begrijp niet goed wat je bedoelt met ‘strak’, kun je dat wat nader omschrijven?), maar ook zo zijn voordelen: als een functie nu een argument meer of minder gaat gebruiken, hoef je nergens de functie-aanroep te veranderen.
Siblr bootst geen ‘goto’ na, maar maakt het gebruik ervan overbodig. Dit geldt eveneens voor multiple returns / exits: dit zijn allemaal dingen die je liever niet ziet in code. Met Siblr spring je bovendien altijd naar dezelfde plaats in een programma.
Siblr dwingt je om na te denken over foutafhandeling door de situatie om te draaien: de meeste ontwerpen zijn doelgericht (doe dit, check dat, doe dat, check dit, etc) en gaan niet in op uitzonderingen.
In de praktijk is gebleken dat slecht enkele ‘Siblr-if’s’ geen foutsituatie opleveren, en het gros wel. Door de confrontatie met deze situaties word je gedwongen meteen een foutboodschap te maken, het fout type te bepalen, en de transactie af te breken. Zo vang je stelselmatig alle functionele fouten af.
Op het technische vlak heeft elke functie natuurlijk een try-catch: in de catch hang je de lokale variabelen als properties aan je object, en zet je ook weer foutboodschap en -type; zo heb je alle informatie in één object, en zijn ook alle technische fouten afgedekt.
Combineer dit met een foutafhandeling die ook nog omgevings variabelen en user settings ophaalt, en je hebt een compleet beeld: het is alsof je naaast de gebruiker stond toen het mis ging.
Ik hoop dat dit een en ander verduidelijkt; voel je vrij om contact met me op te nemen.< BR>
Martijn Linssen
Dick Streefland
