# Apps Script debuggen: loggen, testen en fouten oplossen

Apps Script debuggen is een vaardigheid die je veel tijd bespaart. Code werkt zelden meteen perfect, en de truc is om snel te zien wat er misgaat. In dit artikel leer je loggen, de ingebouwde debugger gebruiken, foutmeldingen lezen en de uitvoeringsgeschiedenis raadplegen, zodat je gericht fouten oplost in plaats van te gokken.

[[TOC]]

## Loggen: je belangrijkste hulpmiddel

De snelste manier om te zien wat je code doet, is waarden loggen. Je hebt twee opties die allebei in het uitvoeringslogboek verschijnen:

```javascript
function debugVoorbeeld() {
  const data = [1, 2, 3];
  Logger.log('Array lengte: ' + data.length);
  console.log('Volledige array:', data);

  data.forEach(function(getal, index) {
    console.log('Index ' + index + ' heeft waarde ' + getal);
  });
}
```

`Logger.log()` is de klassieke methode. `console.log()` werkt ook en kan objecten netter weergeven. Gebruik logging om te controleren of variabelen de waarde hebben die je verwacht. Tijdens een run of in de debugger stromen de logs in real time binnen, zodat je meteen ziet hoever je code komt.

:::info title="Cloud-logging"
Met `console.log()` schrijf je ook naar Cloud Logging, waar je logs van getriggerde, onbemande runs terugvindt. Dat is cruciaal voor triggers die draaien als jij er niet bij bent. Gebruik `console.error()` met een Error-object voor fouten; Apps Script vult dan automatisch de juiste velden in. Zie developers.google.com/apps-script/guides/logging.
:::

## De debugger en breakpoints

Voor lastige fouten gebruik je de ingebouwde debugger. Je zet een breakpoint door op het regelnummer te klikken, kiest Debuggen in plaats van Uitvoeren, en het script pauzeert op die regel. Dan inspecteer je alle variabelen op dat moment.

:::howto title="Stap voor stap debuggen"
1. Beweeg in de editor over het regelnummer waar je wilt pauzeren en klik op het cirkeltje; er verschijnt een **rode stip**.
2. Selecteer bovenin de functie en klik op **Debuggen** in plaats van **Uitvoeren**.
3. Het script stopt bij het breakpoint en toont een tabel met de waarden van variabelen en objecten op dat moment.
4. Gebruik **stap-over** en **stap-in** om regel voor regel verder te gaan.
5. Pas je code aan zodra je ziet waar de waarde afwijkt van wat je verwacht.
:::

## Foutmeldingen en stacktraces lezen

Als je script crasht, verschijnt een rode foutmelding met een regelnummer en een stacktrace. Die stacktrace leest van onder naar boven: bovenaan staat waar de fout optrad, daaronder welke functie die aanriep. Een typische fout:

```javascript
function veroorzaakFout() {
  const blad = SpreadsheetApp.getActiveSpreadsheet().getSheetByName('Bestaatniet');
  blad.getRange('A1').getValue();
}
```

Dit geeft een fout omdat `getSheetByName()` null teruggeeft voor een niet-bestaand blad, en je daarna een methode op null aanroept. De melding TypeError, cannot read properties of null, wijst je precies de oorzaak aan.

:::tip title="null is bijna altijd de boosdoener"
Een melding als cannot read properties of null betekent bijna altijd dat een eerdere aanroep null teruggaf. Werk terug naar de regel ervoor en controleer of dat blad, bestand of element wel bestaat voordat je er een methode op aanroept.
:::

## Defensief programmeren met try-catch

Om te voorkomen dat een fout je hele script stopt, vang je hem op met try-catch. Dat is vooral belangrijk in loops en triggers:

```javascript
function veiligVerwerken() {
  const blad = SpreadsheetApp.getActiveSpreadsheet().getSheetByName('Data');
  const data = blad.getDataRange().getValues();

  data.forEach(function(rij, i) {
    try {
      verwerkRij(rij);
    } catch (fout) {
      console.error('Fout in rij ' + (i + 1) + ': ' + fout.message);
    }
  });
}
```

Zo loopt de verwerking door, ook als een enkele rij een probleem geeft, en log je precies welke rij faalde.

:::warn title="Vang fouten nooit stil op"
Een `catch` zonder enige logging verbergt problemen, waardoor je later niet weet waarom data ontbreekt. Log altijd minstens `fout.message` en genoeg context (zoals het rijnummer) om te zien wat er misging.
:::

## De uitvoeringsgeschiedenis

Klik links op Uitvoeringen voor een overzicht van alle runs: handmatig en getriggerd, met starttijd, duur, status en foutmeldingen. Dit is onmisbaar voor triggers, want daar zit je niet live bij. Een rode status met een melding vertelt je precies wanneer en waarom een onbemande run faalde. Vanuit hetzelfde overzicht spring je door naar de bijbehorende Cloud Logging-regels.

## Een trigger lokaal naspelen

Triggerfuncties krijgen een event-object mee dat je bij een handmatige run niet hebt. Wil je zo'n functie debuggen, log dan eenmalig het echte event-object en bouw daarna een nagemaakt object na om de functie handmatig te testen:

```javascript
function onFormSubmit(e) {
  console.log(JSON.stringify(e));
  verwerkInzending(e);
}

function testNaspelen() {
  const nepEvent = { values: ['2026-06-01', 'test@voorbeeld.nl', 'Hallo'] };
  verwerkInzending(nepEvent);
}
```

Zo debug je de logica zonder telkens een echt formulier in te dienen.

:::faq
### Wat is het verschil tussen Logger.log en console.log?
Beide verschijnen in het uitvoeringslogboek. `console.log` schrijft daarnaast naar Cloud Logging, waardoor je logs van getriggerde runs achteraf terugvindt. Voor losse, snelle checks volstaat `Logger.log`; voor productie en triggers gebruik je `console.log` en `console.error`.

### Waar zie ik fouten van een trigger die 's nachts draaide?
In het overzicht Uitvoeringen en in Cloud Logging. Daar staan ook runs waar je niet bij was, met hun foutmeldingen, starttijd en duur.

### Mijn script stopt zonder duidelijke fout, hoe vind ik de oorzaak?
Voeg `console.log`-regels toe op meerdere plekken om te zien hoever het komt, of zet een breakpoint en debug stap voor stap. Check ook of een eerdere aanroep stilletjes null teruggaf.

### Hoe debug ik een functie die een trigger nodig heeft?
Log eenmalig het echte event-object met `console.log(JSON.stringify(e))`, en bouw daarna een nagemaakt object na zodat je de functie handmatig kunt aanroepen en testen.

### Waarom raakt mijn script soms over de tijdslimiet?
Een run mag maximaal zes minuten duren (dertig minuten voor sommige Workspace-abonnementen). Log de duur per stap of bekijk de duur in Uitvoeringen om te zien welk deel traag is, en verwerk grote datasets in batches.

### Kan ik in de debugger waarden aanpassen?
Nee, de debugger is alleen-lezen: je inspecteert variabelen maar wijzigt ze niet live. Pas je code aan, sla op en draai opnieuw.
:::

## Volgende stap

Goed kunnen debuggen maakt elk ander artikel makkelijker. Pas deze technieken toe op je [[apps-script-formulier-response|formulierverwerking]] en lees over duurzame code in [[apps-script-best-practices|best practices]].