In Visual Basic .NET worden anonieme methoden geïmplementeerd met behulp van lambda-expressies (Function of Sub). Ze maken het mogelijk om kleine codeblokken te definiëren zonder een aparte benoemde procedure te hoeven maken. Voorbeeld van gebruik:
Dim squared = Function(x As Integer) x * x Console.WriteLine(squared(5)) ' Uitvoer: 25 Dim numbers = {1, 2, 3, 4} Dim evens = numbers.Where(Function(n) n Mod 2 = 0) For Each n In evens Console.WriteLine(n) Next
Voordelen:
Beperkingen:
Vraag: "Kan een lambda-expressie worden gebruikt voor het declareren van een procedure met een GoTo-statement erin? Waarom?"
Juiste antwoord: Nee, lambda-expressies in VB.NET laten het gebruik van stroomcontrole-instructies zoals GoTo, GoSub of Label niet toe. Dit is te wijten aan de implementatie-eisen van anonieme methoden. Proberen om GoTo te gebruiken zal een compilatiefout veroorzaken.
Voorbeeldcode (geeft fout):
Dim broken = Sub() GoTo Label1 Label1: End Sub
Verhaal
In een dataverwerkingsproject probeerden ze lambda-expressies te gebruiken voor complexe validatie met meerdere uitgangen via GoTo. Bij de migratie van gewone methoden naar lambda-code kregen ze een compilatiefout, waardoor ze snel de architectuur van de functies moesten wijzigen.
Verhaal
Voor asynchrone oproepen gebruikten ze anonieme methoden. Binnen de lambda verwezen ze per ongeluk naar variabelen die in een lus veranderden. Dit leidde tot onverwachte resultaten, omdat de lambda de variabele per referentie "onthield" in plaats van de waarde — het resultaat waren mysterieuze bugs in de rapporten.
Verhaal
In een project converteten ze anonieme methoden rechtstreeks naar delegaten van incompatibele types (bijv. Sub in plaats van Function). De compiler gaf geen duidelijke foutmelding, maar de gebeurtenisverwerkers werden niet uitgevoerd. Dit werd pas ontdekt tijdens handmatige tests, wat leidde tot vertraging in de release.