Gestion des erreurs et journalisation des exceptions

Apprenez les principes fondamentaux de la gestion des erreurs et de la journalisation des exceptions dans les applications Web Blazor.

Comme dans d’autres cadres de développement Web modernes, la gestion des erreurs et la journalisation des exceptions sont essentiels pour fournir des produits logiciels de haute qualité. Cet article discutera des options et des défis auxquels nous sommes confrontés en les mettant en œuvre avec le développement d’applications Web Blazor.

Tu peux accéder au code utilisé dans cet exemple sur github.

Types d’erreur dans les applications du blazor

Avant de plonger dans des solutions pour gérer des cas d’erreur particuliers, explorons d’abord les différents types d’erreur auxquels une application Web Blazor est confrontée:

• Erreurs d’exécution: Des erreurs côté client et côté serveur se produisent lors de l’exécution de l’application. Par exemple, JavaScript interop, échecs API ou problèmes de connexion à la base de données.
• Erreurs de validation: Les erreurs d’entrée et de validation du formulaire se produisent lors du traitement de la saisie des utilisateurs dans une application Web ou du formulaire de contact d’un site Web d’entreprise.
• Erreurs de configuration: Les erreurs se produisant au cours du démarrage des applications Web Blazor, telles que les dépendances mal configurées et le middleware.
• Erreurs inattendues: Des erreurs de programmation, telles que des exceptions de référence NULL, des exceptions non gérées ou d’autres erreurs inconnues.

Chaque type d’erreur nécessite une approche différente pour les gérer dans nos applications gracieusement.

La stratégie générale de gestion des erreurs pour Blazor

Nous avons quelques options pour gérer les erreurs dans les applications Web Blazor.

Le C # par défaut try-catch Le mécanisme nous permet d’écrire du code défensif pour attraper des exceptions attendues lors de l’exécution d’opérations telles que l’appel d’un service distant ou l’accès au système de fichiers.

Pour contenir des erreurs d’interface utilisateur, nous pouvons implémenter le ErrorBoundary taper. Pour la gestion globale des erreurs, nous enregistrons un gestionnaire d’erreurs dans le Program.cs déposer.

Pour les applications Blazor WebAssembly, nous pouvons intercepter Program.cs déposer.

Semblable aux autres applications .NET, nous devons suivre les meilleures pratiques et envelopper le code critique à l’intérieur d’un try-catch bloc. Par exemple, des opérations IO telles que la lecture ou l’écriture de fichiers ou l’appel des services HTTP.

Dans cet article, nous examinerons les différentes options de gestion des erreurs plus en détail.

Implémentation de limites d’erreur

Chaque fois que nous faisons face à une exception non perdue dans une application de blazor, nous verrons la boîte jaune en bas de l’écran.

Cette boîte d’erreur est définie comme faisant partie du composant mainlayout.razor.

<div id="blazor-error-ui" data-nosnippet>
    An unhandled error has occurred.
    <a href="." class="reload">Reload</a>
    <span class="dismiss">🗙</span>
</div>

Pour Serveur de blazor Application, vous devez actualiser le navigateur après qu’une telle erreur se déroule pour continuer à utiliser l’application Web. Blazor webassembly est plus indulgent et vous permet de continuer à utiliser l’application. Cependant, l’erreur reste en bas de l’écran, sauf si vous la rejetez.

Vous pouvez améliorer l’apparence de l’erreur. Cependant, ce qui est mieux que de le rendre plus attrayant, c’est de l’éviter avant que cela ne se produise. C’est là que Limites d’erreur Entrez en jeu. Les limites d’erreur fournissent un moyen simple d’attraper les erreurs et de contrôler la façon dont ils montent dans la hiérarchie des composants.

Ajoutons une limite d’erreur dans le MainLayout.razor composant:

<div class="page">
    <div class="sidebar">
        <NavMenu />
    </div>

    <main>
        
        <article class="content px-4">
            <ErrorBoundary>
                @Body
            </ErrorBoundary>
        </article>
    </main>
</div>

Le MainLayout Le composant est le même qu’il est généré par le modèle de projet Blazor Web Blazor Applate par défaut. Cependant, nous avons ajouté un ErrorBoundary composant autour du @Body espace réservé.

Nous pouvons également ajouter quelques lignes de CSS au app.css Fichier pour styliser l’apparence de l’erreur rendue:

.blazor-error-boundary {
    background-color: darkred;
    padding: 1rem 1rem 1rem 3.7rem;
    color: white;
}

.blazor-error-boundary::after {
    content: "An error has occurred."
}

L’erreur résultante ressemble à ceci:

En plus de pouvoir contrôler l’apparence et la sensation en utilisant CSS (que vous pouvez également faire pour la barre d’erreur ordinaire en bas), vous pouvez continuer à utiliser l’application au cas où une erreur se produit.

La raison en est que le Limite d’erreur Arrête l’erreur où elle est ajoutée à l’arborescence des composants. Dans ce cas, nous pouvons visiter une autre page, mais la mise en page affichera toujours notre erreur.

Vous pouvez expérimenter avec le ErrorBoundary Tapez et ajoutez-le plus près des erreurs potentielles dans l’arborescence des composants. Cela aide à maintenir les autres parties de l’application en cours d’exécution lorsqu’une erreur se produit dans un emplacement spécifique de l’application.

Vous pouvez également personnaliser le HTML rendu lorsqu’une erreur se produit. Vous pouvez développer l’exemple de code indiqué ci-dessus et utiliser le code suivant:

<ErrorBoundary>
  <ChildContent>
    @Body
  </ChildContent>
  <ErrorContent>
    <div>Customized error display</div>
  </ErrorContent>
</ErrorBoundary>

Dans ce code, le ChildContent Le fragment de rendu contient le contenu rendu lors du fonctionnement normal de l’application.

Si une exception non gérée se produit, le code HTML dans le ErrorContent Le fragment de rendu sera rendu.

Le @context la propriété vous permet d’accéder à l’exception dans le ErrorContent Rendre le fragment. Le code suivant montre le message de l’exception non perdue comme message d’erreur du ErrorBoundary composant.

<article class="content px-4">
    <ErrorBoundary>
        <ChildContent>
            @Body
        </ChildContent>
        <ErrorContent>
            <div>@context.Message</div>
        </ErrorContent>
    </ErrorBoundary>
</article>

L’erreur résultante ressemble à ceci:

Le code suivant montre comment je génère l’exception à l’intérieur du Counter Composant de cette application de démonstration:

private void IncrementCount()
{
    currentCount++;

    if (currentCount > 5)
    {
        throw new NotSupportedException();
    }
}

Se remettre d’une erreur non gérée

Lorsqu’une exception non gérée se produit, le ErrorContent Le fragment de rendu est rendu et la demande reste dans un état opérationnel. Cependant, l’erreur affiche toujours lorsque nous naviguons vers une autre page.

Pour résoudre l’erreur, nous pouvons utiliser le Recover Méthode sur le ErrorBoundary Tapez la section Code.

@code {
    private ErrorBoundary? _errorBoundary;

    protected override void OnParametersSet()
    {
        _errorBoundary?.Recover();
    }
}

Nous devons également ajouter la référence au _errorBoundary champ vers le ErrorBoundary composant dans la section modèle du MainLayout composant:

<ErrorBoundary @ref="_errorBoundary"></ErrorBoundary>

Maintenant, chaque fois qu’une erreur se produit sur la page du compteur, nous pouvons naviguer hors de la page et accéder à n’importe quelle page, et l’application Web est entièrement opérationnelle.

Enfin et surtout, le ErrorBoundary Type a un MaximumErrorCount propriété qui peut être définie sur une valeur entière.

<ErrorBoundary @ref="_errorBoundary" MaximumErrorCount="50">
    <ChildContent>
        @Body
    </ChildContent>
    <ErrorContent>
        <div>@context.Message</div>
    </ErrorContent>
</ErrorBoundary>

Si plus d’exceptions se produisent que ce nombre, le ErrorBoundary Ne contient plus les erreurs et la barre jaune au bas de l’application montre que l’application n’est plus opérationnelle.

Exceptions de journalisation

La journalisation est toujours l’un des outils les plus efficaces pour surveiller les logiciels et déterminer où commencer le débogage en cas d’erreur d’exécution.

Blazor fait partie de ASP.NET Core; Par conséquent, en utilisant la norme ILogger L’interface est le moyen par défaut d’implémenter la journalisation.

@page "/counter"
@inject ILogger<Counter> Logger

<PageTitle>Counter</PageTitle>

<h1>Counter</h1>
<p role="status">Current count: @currentCount</p>
<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>

@code {
    private int currentCount = 0;

    private void IncrementCount()
    {
        Logger.LogInformation("Increment Count: {currentCount}", currentCount);
        currentCount++;
    }
}

Nous pouvons injecter le ILogger Interface dans les composants du rasoir ou les implémentations de service lors de la mise en œuvre d’une application Web Blazor. La valeur par défaut WebApplicationBuilder initialise un Console bûcheron.

Considérez le code suivant à partir d’un composant de page à l’aide du noyau de Framework Entity pour supprimer les données.

try
{
    await ClientService.DeleteClient(client.ClientId);
    await Reload();
    Snackbar.Add($"The client {client.Name} has been deleted.", 
        Severity.Success);
}
catch (DbUpdateException ex)
{
    Logger.LogError("Client could not be deleted: {exception}", ex.Message);
    Snackbar.Add($"Error during deletion of the client. {ex.Message} {ex.InnerException?.Message}", 
        Severity.Error, 
        options => options.RequireInteraction = true);
}

Dans cet exemple de composant de page dans une application de serveur Blazor, nous utilisons un try-catch bloc pour attraper DbUpdateExceptions se produisant lors de la suppression d’un client dans la base de données.

Nous montrons l’erreur à l’utilisateur à l’aide d’un composant de snackbar, et nous enregistrons l’erreur à l’aide du mécanisme de journalisation du noyau ASP.NET avec le LogError Méthode sur le ILogger interface.

Configurer la journalisation

En utilisant le mécanisme de configuration par défaut, vous pouvez définir un niveau de journal par portée, tel que défini dans le appsettings.json Fichier généré à l’aide du modèle de projet d’application Web Blazor:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "AllowedHosts": "*"
}

Dans cette configuration, les informations de niveau de journal s’appliquent à toutes les lunettes qui ne spécifient pas de niveau de journal. Le Microsoft.AspNetCore La portée a Warning comme son niveau de journal. Nous pouvons ajouter des lunettes pour obtenir un contrôle granulaire sur les messages de journal à écrire.

Par exemple, lorsque vous avez un problème avec le flux de commandes de votre boutique en ligne, vous pouvez augmenter le niveau de journal pour cette portée et conserver les autres parties de l’application au niveau du journal ordinaire.

N’oubliez pas que l’utilisation du Niveau de journal correct pour vos messages de journal est crucial.

Vous voulez avoir autant d’informations que possible lors du débogage ou de l’exécution en mode développement, et vous ne souhaitez pas ralentir votre application en production.

Il est de la meilleure pratique de uniquement les avertissements et les erreurs de production.

Meilleures pratiques pour la gestion des erreurs et la journalisation

Les directives suivantes m’aident à gérer et à enregistrer les erreurs dans chaque projet d’application Web Blazor:

1. Utiliser try-catch le cas échéant. Le bon vieux try-catch La déclaration est toujours précieuse pour le développement Web de Blazor et aide à gérer des situations incertaines, telles que les opérations IO.
2. Utilisez la bonne journalisation des erreurs. Il n’y a rien de pire que de ne pas savoir les erreurs qui se produisent dans votre application. Le mécanisme de journalisation de base ASP.NET par défaut est un excellent point de départ.
3. Utiliser ErrorBoundary pour contenir des erreurs d’interface utilisateur. Les limites d’erreur vous aident à garder les lumières allumées en réduisant la zone d’impact d’une exception non gérée. Vous pouvez vous remettre d’une exception non perdue dans de nombreux scénarios avec un peu de travail supplémentaire.
4. Valider l’entrée utilisateur. Lorsque vous travaillez avec les formulaires et la saisie de l’utilisateur, validez les données avant de les traiter dans votre application. Ce n’est pas seulement un risque de sécurité pour traiter la saisie des utilisateurs non validés, mais il s’agit également d’une source d’erreurs parfaite.
5. Gérer les erreurs d’interopération JavaScript. Lorsque vous travaillez avec le IJSRuntime Tapez, joignez tous les appels à l’aide du InvokeVoidAsync (ou similaire) Méthode avec un try-catch déclaration pour attraper tout JSException Exceptions.

Avec ces directives simples, vous serez dans un bon endroit. Vous pouvez toujours aller plus loin, comme l’intégration des cadres de journalisation avancés ou des solutions de surveillance des applications.

Conclusion

Dans cet article, nous avons appris la gestion des erreurs et la journalisation des exceptions dans les applications Web Blazor.

Nous avons appris le type d’erreur, implémentant la journalisation du noyau ASP.NET et les meilleures pratiques de gestion des erreurs et de journalisation des exceptions.

Si vous voulez en savoir plus sur le développement du blazor, vous pouvez regarder mon Cours crash gratuit du blazor sur youtube. Et restez à l’écoute du blog Telerik pour en savoir plus Bases du blazor.