Foutafhandeling en nieuwe pogingen in Azure Functions

Het afhandelen van fouten in Azure Functions is belangrijk om verloren gegevens te voorkomen, gemiste gebeurtenissen te voorkomen en de status van uw toepassing te controleren. Het is ook een belangrijke manier om inzicht te verkrijgen in het gedrag van opnieuw proberen van triggers op basis van gebeurtenissen.

In dit artikel worden algemene strategieën beschreven voor foutafhandeling en de beschikbare strategieën voor opnieuw proberen.

Belangrijk

Preview-beleidsondersteuning voor opnieuw proberen voor bepaalde triggers is in december 2022 verwijderd. Beleid voor opnieuw proberen voor ondersteunde triggers is nu algemeen beschikbaar (GA). Zie de sectie Nieuwe pogingen voor een lijst met extensies die momenteel ondersteuning bieden voor beleid voor opnieuw proberen.

Afhandeling van fouten

Fouten die optreden in een Azure-functie kunnen afkomstig zijn van:

• Gebruik van ingebouwde Functions-triggers en -bindingen.
• Aanroepen naar API's van onderliggende Azure-services.
• Aanroepen naar REST-eindpunten.
• Aanroepen naar clientbibliotheken, pakketten of API's van derden.

Om verlies van gegevens of gemiste berichten te voorkomen, is het belangrijk om goede foutafhandeling te oefenen. In deze tabel worden enkele aanbevolen procedures voor foutafhandeling beschreven en vindt u koppelingen naar meer informatie.

Aanbeveling	DETAILS
Application Insights inschakelen	Azure Functions kan worden geïntegreerd met Application Insights om foutgegevens, prestatiegegevens en runtimelogboeken te verzamelen. U moet Application Insights gebruiken om fouten te detecteren en beter te begrijpen die optreden in uw functie-uitvoeringen. Zie Azure Functions bewaken voor meer informatie.
Gestructureerde foutafhandeling gebruiken	Het vastleggen en vastleggen van fouten in logboekregistratie is essentieel voor het bewaken van de status van uw toepassing. Het hoogste niveau van elke functiecode moet een try/catch-blok bevatten. In het catch-blok kunt u fouten vastleggen en vastleggen. Zie Bindingsfoutcodes voor informatie over welke fouten kunnen worden gegenereerd door bindingen. Afhankelijk van uw specifieke strategie voor opnieuw proberen, kunt u ook een nieuwe uitzondering genereren om de functie opnieuw uit te voeren.
Uw strategie voor opnieuw proberen plannen	Verschillende Functions bindings-extensies bieden ingebouwde ondersteuning voor nieuwe pogingen en andere bieden u de mogelijkheid om beleid voor opnieuw proberen te definiëren, die worden geïmplementeerd door de Functions-runtime. Voor triggers die geen gedrag voor opnieuw proberen bieden, moet u overwegen om uw eigen schema voor opnieuw proberen te implementeren. Zie Nieuwe pogingen voor meer informatie.
Ontwerpen voor idempotentie	Het optreden van fouten bij het verwerken van gegevens kan een probleem zijn voor uw functies, met name wanneer u berichten verwerkt. Het is belangrijk om na te gaan wat er gebeurt wanneer de fout optreedt en hoe u dubbele verwerking kunt voorkomen. Zie Azure Functions ontwerpen voor identieke invoer voor meer informatie.

Nieuwe pogingen

Er zijn twee soorten nieuwe pogingen beschikbaar voor uw functies:

• Ingebouwd gedrag voor opnieuw proberen van afzonderlijke triggerextensies
• Beleid voor opnieuw proberen dat wordt geleverd door de Functions-runtime

De volgende tabel geeft aan welke triggers ondersteuning bieden voor nieuwe pogingen en waar het gedrag voor opnieuw proberen is geconfigureerd. Het bevat ook koppelingen naar meer informatie over fouten die afkomstig zijn van de onderliggende services.

Trigger/binding	Bron voor opnieuw proberen	Configuratie
Azure Cosmos DB	Beleid voor opnieuw proberen	Functieniveau
Blob Storage	Bindingsextensie	host.json
Event Grid	Bindingsextensie	Gebeurtenisabonnement
Event Hubs	Beleid voor opnieuw proberen	Functieniveau
Kafka	Beleid voor opnieuw proberen	Functieniveau
Queue Storage	Bindingsextensie	host.json
RabbitMQ	Bindingsextensie	Wachtrij met dode letters
Service Bus	Bindingsextensie	host.json*
Timer	Beleid voor opnieuw proberen	Functieniveau

^*Vereist versie 5.x van de Azure Service Bus-extensie. In oudere uitbreidingsversies worden gedrag voor opnieuw proberen geïmplementeerd door de Service Bus dead letter queue.

Beleid opnieuw proberen

Met Azure Functions kunt u beleid voor opnieuw proberen definiëren voor specifieke triggertypen, die worden afgedwongen door de runtime. Deze triggertypen ondersteunen momenteel beleid voor opnieuw proberen:

• Azure Cosmos DB
• Event Hubs
• Kafka
• Timer

Ondersteuning voor opnieuw proberen is hetzelfde voor zowel v1- als v2 Python-programmeermodellen.

Beleid voor opnieuw proberen wordt niet ondersteund in versie 1.x van de Functions-runtime.

Het beleid voor opnieuw proberen geeft aan dat de runtime een mislukte uitvoering opnieuw uitvoert totdat de voltooiing is voltooid of het maximum aantal nieuwe pogingen is bereikt.

Er wordt een beleid voor opnieuw proberen geëvalueerd wanneer een functie die wordt uitgevoerd door een ondersteund triggertype, een niet-onderschepte uitzondering genereert. Als best practice moet u alle uitzonderingen in uw code onderscheppen en nieuwe uitzonderingen genereren voor eventuele fouten die u wilt resulteren in een nieuwe poging.

Belangrijk

Controlepunten voor Event Hubs worden pas geschreven nadat het beleid voor opnieuw proberen voor de uitvoering is voltooid. Vanwege dit gedrag wordt de voortgang van de specifieke partitie onderbroken totdat de huidige batch is verwerkt.

De versie 5.x van de Event Hubs-extensie biedt ondersteuning voor extra mogelijkheden voor opnieuw proberen voor interacties tussen de Functions-host en de Event Hub. Zie de naslaginformatie voor Event Hubs host.json voor meer informatieclientRetryOptions.

Strategieën voor opnieuw proberen

U kunt twee strategieën voor opnieuw proberen configureren die worden ondersteund door beleid:

Vaste vertraging

Er mag een opgegeven tijdsduur tussen elke nieuwe poging worden verstreken.

Exponentieel uitstel

De eerste poging wacht op de minimale vertraging. Bij volgende nieuwe pogingen wordt de tijd exponentieel toegevoegd aan de eerste duur voor elke nieuwe poging, totdat de maximale vertraging is bereikt. Exponentieel uitstel voegt een kleine randomisatie toe aan vertragingen bij het herverspringen van nieuwe pogingen in scenario's met hoge doorvoer.

Wanneer u een verbruiksabonnement uitvoert, wordt u alleen gefactureerd voor het moment dat uw functiecode wordt uitgevoerd. Er worden geen kosten in rekening gebracht voor de wachttijd tussen uitvoeringen in een van deze strategieën voor opnieuw proberen.

Maximumaantal nieuwe pogingen

U kunt het maximum aantal keren configureren dat een functie-uitvoering opnieuw wordt uitgevoerd voordat er uiteindelijk een fout optreedt. Het huidige aantal nieuwe pogingen wordt opgeslagen in het geheugen van het exemplaar.

Het is mogelijk dat een exemplaar een fout heeft tussen nieuwe pogingen. Wanneer een exemplaar mislukt tijdens een beleid voor opnieuw proberen, gaat het aantal nieuwe pogingen verloren. Wanneer er fouten optreden in het exemplaar, kan de Event Hubs-trigger de verwerking hervatten en de batch opnieuw uitvoeren op een nieuw exemplaar, waarbij het aantal nieuwe pogingen opnieuw wordt ingesteld op nul. De timertrigger wordt niet hervat op een nieuw exemplaar.

Dit gedrag betekent dat het maximale aantal nieuwe pogingen een best effort is. In sommige zeldzame gevallen kan een uitvoering meer dan het aangevraagde maximum aantal keren opnieuw worden geprobeerd. Voor timertriggers kunnen de nieuwe pogingen kleiner zijn dan het maximumaantal dat is aangevraagd.

Voorbeelden van nieuwe pogingen

Er worden voorbeelden gegeven voor zowel vaste vertragings- als exponentiële uitstelstrategieën. Als u voorbeelden voor een specifieke strategie wilt zien, moet u die strategie eerst selecteren op het vorige tabblad.

Geïsoleerde werkrolmodel

Nieuwe pogingen op functieniveau worden ondersteund met de volgende NuGet-pakketten:

• Microsoft.Azure.Functions.Worker.Sdk>= 1.9.0
• Microsoft.Azure.Functions.Worker.Extensions.EventHubs>= 5.2.0
• Microsoft.Azure.Functions.Worker.Extensions.Kafka>= 3.8.0
• Microsoft.Azure.Functions.Worker.Extensions.Timer>= 4.2.0

[Function(nameof(TimerFunction))]
[FixedDelayRetry(5, "00:00:10")]
public static void Run([TimerTrigger("0 */5 * * * *")] TimerInfo timerInfo,
    FunctionContext context)
{
    var logger = context.GetLogger(nameof(TimerFunction));
    logger.LogInformation($"Function Ran. Next timer schedule = {timerInfo.ScheduleStatus.Next}");
}

Eigenschappen	Beschrijving
MaxRetryCount	Vereist. Het maximum aantal nieuwe pogingen dat is toegestaan per functie-uitvoering. -1 betekent dat u het voor onbepaalde tijd opnieuw wilt proberen.
DelayInterval	De vertraging die wordt gebruikt tussen nieuwe pogingen. Geef deze op als een tekenreeks met de notatie HH:mm:ss.

Model in proces

Nieuwe pogingen vereisen NuGet-pakket Microsoft.Azure.WebJobs>= 3.0.23

[FunctionName("EventHubTrigger")]
[FixedDelayRetry(5, "00:00:10")]
public static async Task Run([EventHubTrigger("myHub", Connection = "EventHubConnection")] EventData[] events, ILogger log)
{
// ...
}

Eigenschappen	Beschrijving
MaxRetryCount	Vereist. Het maximum aantal nieuwe pogingen dat is toegestaan per functie-uitvoering. -1 betekent dat u het voor onbepaalde tijd opnieuw wilt proberen.
DelayInterval	De vertraging die wordt gebruikt tussen nieuwe pogingen. Geef deze op als een tekenreeks met de notatie HH:mm:ss.

Geïsoleerde werkrolmodel

Nieuwe pogingen op functieniveau worden ondersteund met de volgende NuGet-pakketten:

• Microsoft.Azure.Functions.Worker.Sdk>= 1.9.0
• Microsoft.Azure.Functions.Worker.Extensions.EventHubs>= 5.2.0
• Microsoft.Azure.Functions.Worker.Extensions.Kafka>= 3.8.0
• Microsoft.Azure.Functions.Worker.Extensions.Timer>= 4.2.0

[Function(nameof(CosmosDBFunction))]
[ExponentialBackoffRetry(5, "00:00:04", "00:15:00")]
[CosmosDBOutput("%CosmosDb%", "%CosmosContainerOut%", Connection = "CosmosDBConnection", CreateIfNotExists = true)]
public object Run(
    [CosmosDBTrigger(
        "%CosmosDb%",
        "%CosmosContainerIn%",
        Connection = "CosmosDBConnection",
        LeaseContainerName = "leases",
        CreateLeaseContainerIfNotExists = true)] IReadOnlyList<MyDocument> input,
    FunctionContext context)
{
    if (input != null && input.Any())
    {
        foreach (var doc in input)
        {
            _logger.LogInformation("Doc Id: {id}", doc.Id);
        }

        // Cosmos Output
        return input.Select(p => new { id = p.Id });
    }

    return null;
}

Model in proces

Nieuwe pogingen vereisen NuGet-pakket Microsoft.Azure.WebJobs>= 3.0.23

[FunctionName("EventHubTrigger")]
[ExponentialBackoffRetry(5, "00:00:04", "00:15:00")]
public static async Task Run([EventHubTrigger("myHub", Connection = "EventHubConnection")] EventData[] events, ILogger log)
{
// ...
}

Eigenschappen	Beschrijving
MaxRetryCount	Vereist. Het maximum aantal nieuwe pogingen dat is toegestaan per functie-uitvoering. -1 betekent dat u het voor onbepaalde tijd opnieuw wilt proberen.
MinimumInterval	De minimale vertraging voor opnieuw proberen. Geef deze op als een tekenreeks met de notatie HH:mm:ss.
MaximumInterval	De maximale vertraging voor opnieuw proberen. Geef deze op als een tekenreeks met de notatie HH:mm:ss.

Hier volgt een voorbeeld van een beleid voor opnieuw proberen dat is gedefinieerd in het function.json-bestand :

Vaste vertraging

{
    "disabled": false,
    "bindings": [
        {
            ....
        }
    ],
    "retry": {
        "strategy": "fixedDelay",
        "maxRetryCount": 4,
        "delayInterval": "00:00:10"
    }
}

Exponentieel uitstel

{
    "disabled": false,
    "bindings": [
        {
            ....
        }
    ],
    "retry": {
        "strategy": "exponentialBackoff",
        "maxRetryCount": 5,
        "minimumInterval": "00:00:10",
        "maximumInterval": "00:15:00"
    }
}

U kunt deze eigenschappen instellen voor beleidsdefinities voor opnieuw proberen:

Eigenschappen	Beschrijving
Strategie	Vereist. De strategie voor opnieuw proberen die moet worden gebruikt. Geldige waarden zijn fixedDelay of exponentialBackoff.
maxRetryCount	Vereist. Het maximum aantal nieuwe pogingen dat is toegestaan per functie-uitvoering. -1 betekent dat u het voor onbepaalde tijd opnieuw wilt proberen.
delayInterval	De vertraging die wordt gebruikt tussen nieuwe pogingen wanneer u een fixedDelay strategie gebruikt. Geef deze op als een tekenreeks met de notatie HH:mm:ss.
minimumInterval	De minimale vertraging voor opnieuw proberen wanneer u een exponentialBackoff strategie gebruikt. Geef deze op als een tekenreeks met de notatie HH:mm:ss.
maximumInterval	De maximale vertraging voor opnieuw proberen wanneer u een strategie gebruikt exponentialBackoff . Geef deze op als een tekenreeks met de notatie HH:mm:ss.

De manier waarop u het beleid voor opnieuw proberen voor de trigger definieert, is afhankelijk van uw Node.js versie.

Node.js v4

Hier volgt een voorbeeld van een timertriggerfunctie die gebruikmaakt van een strategie voor opnieuw proberen met een vaste vertraging:

const { app } = require('@azure/functions');

app.timer('timerTriggerWithRetry', {
    schedule: '0 */5 * * * *',
    retry: {
        strategy: 'fixedDelay',
        delayInterval: {
            seconds: 10,
        },
        maxRetryCount: 4,
    },
    handler: (myTimer, context) => {
        if (context.retryContext?.retryCount < 2) {
            throw new Error('Retry!');
        } else {
            context.log('Timer function processed request.');
        }
    },
});

Node.js v3

Hier volgt een voorbeeld van een beleid voor een vaste vertraging die is gedefinieerd in het function.json-bestand :

{
    "disabled": false,
    "bindings": [
        {
            ....
        }
    ],
    "retry": {
        "strategy": "fixedDelay",
        "maxRetryCount": 4,
        "delayInterval": "00:00:10"
    }
}

De manier waarop u het beleid voor opnieuw proberen voor de trigger definieert, is afhankelijk van uw Node.js versie.

Node.js v4

Hier volgt een voorbeeld van een timertriggerfunctie die gebruikmaakt van een strategie voor opnieuw proberen met een vaste vertraging:

import { app, InvocationContext, Timer } from '@azure/functions';

export async function timerTriggerWithRetry(myTimer: Timer, context: InvocationContext): Promise<void> {
    if (context.retryContext?.retryCount < 2) {
        throw new Error('Retry!');
    } else {
        context.log('Timer function processed request.');
    }
}

app.timer('timerTriggerWithRetry', {
    schedule: '0 */5 * * * *',
    retry: {
        strategy: 'fixedDelay',
        delayInterval: {
            seconds: 10,
        },
        maxRetryCount: 4,
    },
    handler: timerTriggerWithRetry,
});

Node.js v3

Hier volgt een voorbeeld van een beleid voor een vaste vertraging die is gedefinieerd in het function.json-bestand :

{
    "disabled": false,
    "bindings": [
        {
            ....
        }
    ],
    "retry": {
        "strategy": "fixedDelay",
        "maxRetryCount": 4,
        "delayInterval": "00:00:10"
    }
}

U kunt deze eigenschappen instellen voor beleidsdefinities voor opnieuw proberen:

Eigenschappen	Beschrijving
Strategie	Vereist. De strategie voor opnieuw proberen die moet worden gebruikt. Geldige waarden zijn fixedDelay of exponentialBackoff.
maxRetryCount	Vereist. Het maximum aantal nieuwe pogingen dat is toegestaan per functie-uitvoering. -1 betekent dat u het voor onbepaalde tijd opnieuw wilt proberen.
delayInterval	De vertraging die wordt gebruikt tussen nieuwe pogingen wanneer u een fixedDelay strategie gebruikt. Geef deze op als een tekenreeks met de notatie HH:mm:ss.
minimumInterval	De minimale vertraging voor opnieuw proberen wanneer u een exponentialBackoff strategie gebruikt. Geef deze op als een tekenreeks met de notatie HH:mm:ss.
maximumInterval	De maximale vertraging voor opnieuw proberen wanneer u een strategie gebruikt exponentialBackoff . Geef deze op als een tekenreeks met de notatie HH:mm:ss.

Python v2-model

Hier volgt een voorbeeld van een timertriggerfunctie die gebruikmaakt van een strategie voor opnieuw proberen met een vaste vertraging:

import logging

from azure.functions import AuthLevel, Context, FunctionApp, TimerRequest

app = FunctionApp(http_auth_level=AuthLevel.ANONYMOUS)


@app.timer_trigger(schedule="*/1 * * * * *", arg_name="mytimer",
                   run_on_startup=False,
                   use_monitor=False)
@app.retry(strategy="fixed_delay", max_retry_count="3",
           delay_interval="00:00:01")
def mytimer(mytimer: TimerRequest, context: Context) -> None:
    logging.info(f'Current retry count: {context.retry_context.retry_count}')

    if context.retry_context.retry_count == \
            context.retry_context.max_retry_count:
        logging.info(
            f"Max retries of {context.retry_context.max_retry_count} for "
            f"function {context.function_name} has been reached")
    else:
        raise Exception("This is a retryable exception")

Python v2-model

Hier volgt een voorbeeld van een timertriggerfunctie die gebruikmaakt van een strategie voor exponentieel uitstel:

import logging

from azure.functions import AuthLevel, Context, FunctionApp, TimerRequest

app = FunctionApp(http_auth_level=AuthLevel.ANONYMOUS)


@app.timer_trigger(schedule="*/1 * * * * *", arg_name="mytimer",
                   run_on_startup=False,
                   use_monitor=False)
@app.retry(strategy="exponential_backoff", max_retry_count="3",
           minimum_interval="00:00:01",
           maximum_interval="00:00:02")
def mytimer(mytimer: TimerRequest, context: Context) -> None:
    logging.info(f'Current retry count: {context.retry_context.retry_count}')

    if context.retry_context.retry_count == \
            context.retry_context.max_retry_count:
        logging.info(
            f"Max retries of {context.retry_context.max_retry_count} for "
            f"function {context.function_name} has been reached")
    else:
        raise Exception("This is a retryable exception")

Python v1-model

Het beleid voor opnieuw proberen wordt gedefinieerd in het bestand function.json:

{
    "disabled": false,
    "bindings": [
        {
            ....
        }
    ],
    "retry": {
        "strategy": "fixedDelay",
        "maxRetryCount": 4,
        "delayInterval": "00:00:10"
    }
}

Hier volgt een voorbeeld van een timertriggerfunctie die gebruikmaakt van een strategie voor opnieuw proberen met een vaste vertraging:

import azure.functions
import logging


def main(mytimer: azure.functions.TimerRequest, context: azure.functions.Context) -> None:
    logging.info(f'Current retry count: {context.retry_context.retry_count}')

    if context.retry_context.retry_count == context.retry_context.max_retry_count:
        logging.warn(
            f"Max retries of {context.retry_context.max_retry_count} for "
            f"function {context.function_name} has been reached")

Python v1-model

Hier volgt een voorbeeld van een beleid voor exponentieel uitstel dat is gedefinieerd in het bestand function.json :

{
    "disabled": false,
    "bindings": [
        {
            ....
        }
    ],
    "retry": {
        "strategy": "exponentialBackoff",
        "maxRetryCount": 5,
        "minimumInterval": "00:00:10",
        "maximumInterval": "00:15:00"
    }
}

U kunt deze eigenschappen instellen voor beleidsdefinities voor opnieuw proberen:

Python v2-model

Eigenschappen	Beschrijving
Strategie	Vereist. De strategie voor opnieuw proberen die moet worden gebruikt. Geldige waarden zijn fixed_delay of exponential_backoff.
max_retry_count	Vereist. Het maximum aantal nieuwe pogingen dat is toegestaan per functie-uitvoering. -1 betekent dat u het voor onbepaalde tijd opnieuw wilt proberen.
delay_interval	De vertraging die wordt gebruikt tussen nieuwe pogingen wanneer u een fixed_delay strategie gebruikt. Geef deze op als een tekenreeks met de notatie HH:mm:ss.
minimum_interval	De minimale vertraging voor opnieuw proberen wanneer u een exponential_backoff strategie gebruikt. Geef deze op als een tekenreeks met de notatie HH:mm:ss.
maximum_interval	De maximale vertraging voor opnieuw proberen wanneer u een strategie gebruikt exponential_backoff . Geef deze op als een tekenreeks met de notatie HH:mm:ss.

Python v1-model

Eigenschappen	Beschrijving
Strategie	Vereist. De strategie voor opnieuw proberen die moet worden gebruikt. Geldige waarden zijn fixedDelay of exponentialBackoff.
maxRetryCount	Vereist. Het maximum aantal nieuwe pogingen dat is toegestaan per functie-uitvoering. -1 betekent dat u het voor onbepaalde tijd opnieuw wilt proberen.
delayInterval	De vertraging die wordt gebruikt tussen nieuwe pogingen wanneer u een fixedDelay strategie gebruikt. Geef deze op als een tekenreeks met de notatie HH:mm:ss.
minimumInterval	De minimale vertraging voor opnieuw proberen wanneer u een exponentialBackoff strategie gebruikt. Geef deze op als een tekenreeks met de notatie HH:mm:ss.
maximumInterval	De maximale vertraging voor opnieuw proberen wanneer u een strategie gebruikt exponentialBackoff . Geef deze op als een tekenreeks met de notatie HH:mm:ss.

Vaste vertraging

@FunctionName("TimerTriggerJava1")
@FixedDelayRetry(maxRetryCount = 4, delayInterval = "00:00:10")
public void run(
    @TimerTrigger(name = "timerInfo", schedule = "0 */5 * * * *") String timerInfo,
    final ExecutionContext context
) {
    context.getLogger().info("Java Timer trigger function executed at: " + LocalDateTime.now());
}

Exponentieel uitstel

@FunctionName("TimerTriggerJava1")
@ExponentialBackoffRetry(maxRetryCount = 5 , maximumInterval = "00:15:00", minimumInterval = "00:00:10")
public void run(
    @TimerTrigger(name = "timerInfo", schedule = "0 */5 * * * *") String timerInfo,
    final ExecutionContext context
) {
    context.getLogger().info("Java Timer trigger function executed at: " + LocalDateTime.now());
}

Element	Beschrijving
maxRetryCount	Vereist. Het maximum aantal nieuwe pogingen dat is toegestaan per functie-uitvoering. -1 betekent dat u het voor onbepaalde tijd opnieuw wilt proberen.
delayInterval	De vertraging die wordt gebruikt tussen nieuwe pogingen wanneer u een fixedDelay strategie gebruikt. Geef deze op als een tekenreeks met de notatie HH:mm:ss.
minimumInterval	De minimale vertraging voor opnieuw proberen wanneer u een exponentialBackoff strategie gebruikt. Geef deze op als een tekenreeks met de notatie HH:mm:ss.
maximumInterval	De maximale vertraging voor opnieuw proberen wanneer u een strategie gebruikt exponentialBackoff . Geef deze op als een tekenreeks met de notatie HH:mm:ss.

Bindingsfoutcodes

Wanneer u integreert met Azure-services, kunnen fouten afkomstig zijn van de API's van de onderliggende services. Informatie met betrekking tot bindingsspecifieke fouten is beschikbaar in de secties Uitzonderingen en retourcodes van de volgende artikelen:

• Azure Cosmos DB
• Blob Storage
• Event Grid
• Event Hubs
• IoT Hub
• Notification Hubs
• Queue Storage
• Service Bus
• Table Storage

Volgende stappen

• Concepten van Azure Functions-triggers en -bindingen
• Aanbevolen procedures voor betrouwbare Azure-functies