Waarom exceptions cruciaal zijn in een modern dataplatform
Als we het hebben over “opvoeden” in een dataplatform, denken de meeste mensen aan het verhogen van datakwaliteit, performance of businesswaarde. Maar er is iets veel fundamentelers dat we consequent moeten opvoeden: exceptions.
In moderne platforms zoals Microsoft Fabric gooien datapipelines en notebooks standaard exceptions op. Ze waarschuwen als er iets misgaat. Ze stoppen foute transformaties voordat ze verder lopen. Ze voorkomen stille datacorruptie.
Toch wordt deze basisregel in custom logica, notebooks én pipelines, regelmatig vergeten. En daar begint het mis te gaan.
Wanneer “try… except” wordt “try… accepteer alles”
In meerdere projecten en codebases kom ik steeds hetzelfde patroon tegen.
Dit ziet er onschuldig uit. Het voelt netjes. Maar in een productie-dataplatform is dit het equivalent van gebroken glas onder het tapijt vegen. De notebook ziet de cel als “geslaagd”. De notebook sluit “succesvol” af. De Fabric-pipeline toont een groen vinkje.
Ondertussen is er ergens een bestand niet geladen, of heeft een API onvolledige data teruggegeven. En niemand weet het. Niet de engineer. Niet de product owner. Niet de business. De fout werd gevangen, maar de waarheid werd niet opgegooid.
Waarom goede exceptions goede platforms maken
Goede data-engineering draait niet om het onderdrukken van fouten. Het draait om het vroeg, luid en duidelijk zichtbaar maken ervan. Wie exceptions goed opgooit, krijgt:
- Duidelijke pipeline-fouten
- Snellere debugging
- Nauwkeurige operationele monitoring
- Betere data lineage en root cause analyse
- Sterkere governance
- Hogere databetrouwbaarheid
Dit is in Fabric extra belangrijk, omdat pipelines en events afhankelijk zijn van een correcte runtime-status, inclusief fouten.
Het juiste patroon: try waar nodig, raise altijd
Als je een exception echt moet opvangen voor een retry, logging, opruimen of een eigen foutmelding, gooi hem dan altijd opnieuw op.
De log is nuttig. Maar de raise is noodzakelijk. Hij zorgt ervoor dat jouw pipeline en alle bovenliggende code de werkelijkheid weerspiegelen.
Notebooks vs. pipelines: een snelle realitycheck
Notebooks werken correct totdat je try gaat gebruiken. De valkuil zit in het except-gedeelte. Gebruik het niet om exceptions te slikken, maar om iets aan te passen en opnieuw te proberen, of om extra acties uit te voeren. Sluit het except-blok altijd af met raise. Alleen in zeer uitzonderlijke gevallen kies je ervoor niet te raisen en alleen voor specifieke exceptions.
Data Pipelines werken correct totdat je andere precedent constraints gebruikt dan on-success (de groene lijnen). On-completion (blauw), on-fail (rood) en on-skipped (grijs) openen het risico op het onbedoeld slikken van exceptions. De regel die bepaalt of een pipeline als mislukt wordt gerapporteerd, is namelijk gebaseerd op uitsluitend de laatste uitgevoerde activiteit van elke branch, de leaf activities. Dit gedrag wordt uitgelegd in de Azure Data Factory-documentatie en geldt ook voor Fabric-pipelines.
Een veelvoorkomend patroon is het versturen van een e-mail bij een fout. De pipeline stuurt de e-mail als de taak mislukt, maar de pipeline zelf wordt als geslaagd gerapporteerd, omdat de leaf activity (de e-mailtaak) succesvol is afgerond. Hetzelfde risico bestaat bij on-completion en on-skipped.
Gebruik alternatieven voor on-success daarom alleen als het echt nodig is. En als je ze gebruikt, voeg dan een expliciet Fail-activiteit toe, zodat de pipeline-uitvoering als mislukt wordt gemarkeerd. Je kunt meerdere Fail-activiteiten in dezelfde pipeline plaatsen. Ook als een Fail-activiteit wordt uitgevoerd, verwerkt de pipeline alle toegestane activiteiten. Pas daarna rapporteert de pipeline een mislukte run.
Het belang van… eerlijkheid in code én pipelines
Zoals het beroemde toneelstuk ons herinnert: eerlijk zijn van het begin af aan voorkomt veel problemen later. Hetzelfde geldt voor exceptions.
Wil je dat jouw dataplatform voorspelbaar gedraagt, dan moeten exceptions omhoog borrelen naar de orchestratielaag waar ze thuishoren. Wanneer fouten duidelijk zichtbaar zijn, wordt het leven eenvoudiger: pipelines gedragen zich voorspelbaar, teams debuggen sneller en het platform blijft betrouwbaar.
Exceptions goed opvoeden is niet streng of dramatisch. Het is gewoon zorgen dat de juiste systemen kunnen reageren op wat er echt gebeurt.
Goed opgevoede exceptions maken goed draaiende dataplatforms.
