`RECORD_VERSION`

Pour ce niveau d’isolement, l’une des deux valeurs caractéristiques supplémentaires peut être spécifiée, en fonction de la méthode de résolution des conflits souhaitée : RECORD_VERSION et NO RECORD_VERSION.Comme le montrent leurs noms, ils s’excluent mutuellement.

NO RECORD_VERSION est une sorte de mécanisme de verrouillage à deux phases. Dans ce cas, une transaction ne peut pas lire un enregistrement qui a été modifié par une transaction active concurrente (non confirmée).
- Si la stratégie de résolution des verrouillages NO WAIT est spécifiée, une exception sera immédiatement levée.
- Si la stratégie de résolution des verrouillages WAIT est spécifiée, elle fera en sorte qu’une transaction concurrente attende la fin ou le retour en arrière.Si une transaction concurrente est annulée ou si elle est terminée et que son identifiant est plus ancien (plus petit) que celui de la transaction en cours, les modifications de la transaction en cours sont autorisées.Si une transaction concurrente est terminée et que son identifiant est plus récent (plus grand) que l’identifiant de la transaction actuelle, une erreur de conflit de verrouillage sera générée.
Lorsque vous spécifiez RECORD_VERSION, la transaction lit toujours la dernière version validée des enregistrements de la table, qu’il existe ou non des versions modifiées et non validées de ces enregistrements. Dans ce cas, le mode de résolution du verrouillage (WAIT ou NO WAIT) n’a aucun effet sur le comportement de démarrage d’une transaction.

Dans l’API Firebird, le mode de résolution de conflit NO RECORD_VERSION est représenté par la constante isc_tpb_no_rec_version,et RECORD_VERSION — isc_tpb_rec_version.

Warning

A partir de Firebird 4.0, ces options sont obsolètes. Par défaut, elles sont ignorées et la transaction READ COMMITTED READ CONSISTENCY est lancée. Cela peut être modifié en mettant le ReadConsistency (voir firebird.conf) à 0. Dans ce cas, les options ne sont pas ignorées et fonctionnent exactement comme dans les versions précédentes. Dans les versions futures, ce paramètre dans firebird.conf peut être supprimé.

`READ CONSISTENCY`

Si cette option est spécifiée, la transaction en mode d’isolation READ COMMITED prend un instantané persistant de la base de données pour la durée de l’instruction. Chaque nouvelle instruction de niveau supérieur crée son propre instantané de la base de données pour voir les dernières données validées. Les instructions imbriquées (triggers, procédures et fonctions stockées imbriquées, instructions dynamiques, etc.) utilisent le même instantané de la base de données que celui créé par l’instruction de niveau supérieur.

Dans l’API Firebird, la constante isc_tpb_read_consistency correspond à l’opérateur READ CONSISTENCY pour un instantané cohérent au niveau SQL.

Gestion des conflits de mise à jour

Lorsqu’une instruction est exécutée dans une transaction en mode d’isolation READ COMMITTED READ CONSISTENCY, la vue de la base de données est inchangée (similaire à une transaction SNAPSHOT). Le comportement de lecture est similaire à celui de la transaction READ COMMITTED RECORD_VERSION — l’opérateur n’attend pas que la transaction active soit terminée et parcourt la chaîne arrière, qui recherche la version de l’enregistrement visible dans le snapshot courant.

Pour le mode d’isolation READ COMMITTED READ CONSISTENCY, la gestion des conflits de mise à jour de Firebird est considérablement modifiée. Lorsqu’un conflit de mise à jour est détecté, la procédure suivante est effectuée :

le mode d’isolation de la transaction est temporairement commuté sur READ COMMITTED NO RECORD VERSION ;
Firebird pose un verrou sur l’enregistrement en conflit ;
Firebird continue à évaluer les enregistrements restants pour les supprimer/mettre à jour dans le curseur, et continue à poser des verrous sur eux ;
lorsqu’il n’y a plus d’enregistrements à extraire, un mécanisme est déclenché pour annuler toutes les actions effectuées par l’opérateur de niveau supérieur, et tous les verrous posés pour chaque enregistrement mis à jour/supprimé/bloqué sont conservés, tous les enregistrements insérés sont supprimés ;
alors Firebird restaure le mode d’isolation de la transaction en tant que READ COMMITTED READ CONSISTENCY, crée un nouvel instantané de niveau opérateur et relance l’exécution de l’instruction de niveau supérieur.

Cet algorithme garantit que, après le redémarrage, les enregistrements déjà mis à jour restent verrouillés, qu’ils sont visibles pour le nouvel instantané et qu’ils peuvent être mis à jour à nouveau sans autre conflit.De plus, grâce au mode de cohérence de lecture, l’ensemble des enregistrements modifiés reste cohérent.

Note

Remarques

L’algorithme de redémarrage ci-dessus s’applique aux opérateurs UPDATE, DELETE, SELECT WITH LOCK et MERGE, avec ou sans clause RETURNING, exécutés directement depuis l’application utilisateur ou en tant que partie d’un objet PSQL (procédure stockée, fonction, déclencheur, EXECUTE BLOCK etc ;)
Si un opérateur de haut niveau UPDATE/DELETE est situé à un curseur explicite (WHERE CURRENT OF), Firebird saute l’étape (c) ci-dessus, c’est-à-dire qu’il ne récupère pas et ne pose pas de verrous pour les enregistrements restants du curseur ;
Si une instruction SELECT de niveau supérieur (ou un ensemble de données de retour EXECUTE BLOCK) et un conflit de mise à jour se produisent après qu’un ou plusieurs enregistrements ont été renvoyés à l’application, l’erreur de conflit de mise à jour est signalée comme normale et un redémarrage n’est pas lancé ;
le redémarrage n’est pas initié pour les opérateurs en blocs autonomes (IN AUTONOMOUS TRANSACTION DO …) ;
après 10 tentatives, Firebird abandonne l’algorithme de redémarrage, supprime tous les verrous d’écriture, restaure le mode d’isolation de la transaction en tant que READ COMMITTED READ CONSISTENCY et signale un conflit de mise à jour ;
toute erreur non traitée à l’étape (c) ci-dessus arrête l’algorithme de redémarrage et Firebird continue le traitement de manière normale, c’est-à-dire que l’erreur peut être interceptée et traitée par le bloc PSQL WHEN ou signalée à l’application si elle n’est pas traitée ;
Les déclencheurs UPDATE/DELETE seront déclenchés plusieurs fois pour le même enregistrement si l’exécution de la déclaration a été relancée et l’enregistrement mis à jour/supprimé à nouveau ;
pour des raisons historiques, isc_update_conflict est signalé comme un code d’erreur secondaire avec le code d’erreur primaire isc_deadlock.

docnext count = 11

`NO AUTO UNDO`

Lorsque vous utilisez l’option NO AUTO UNDO, l’instruction ROLLBACK marque seulement la transaction comme étant annulée sans supprimer les versions créées dans cette transaction, qui seront supprimées plus tard selon la politique de collecte des déchets sélectionnée (voir le paramètre GCPolicy dans firebird.conf).

Cette option peut être utile pour une transaction dans laquelle de nombreuses déclarations individuelles modifiant les données sont effectuées, et il est certain que la transaction se terminera le plus souvent avec succès plutôt que d’être annulée.

Pour les transactions dans lesquelles aucune modification n’est effectuée, l’option NO AUTO UNDO est ignorée.

`IGNORE LIMBO`

L’option IGNORE LIMBO ignore les enregistrements créés par des transactions lost (c’est-à-dire non complétées) (transaction limbo). Une transaction est considérée comme "perdue" si le deuxième commit en deux phases n’a pas été effectué.

AUTO COMMIT

Si l’option AUTO COMMIT est spécifiée, la transaction est automatiquement confirmée après l’exécution d’une instruction. Si une erreur se produit pendant l’exécution de l’instruction, la transaction sera annulée. Après confirmation ou annulation, la transaction continue d’être active, en conservant son identifiant.

Important

L’option AUTO COMMIT utilise une confirmation soft (COMMIT RETAIN) et un rollback soft (ROLLBACK RETAIN) de la transaction. La confirmation soft ne libère pas les ressources du serveur et retarde la collecte des déchets, ce qui peut avoir un impact négatif sur les performances.

RESERVING

La clause RESERVING de l’instruction SET TRANSACTION réserve les tables spécifiées dans la liste.La réservation interdit aux autres transactions d’apporter des modifications à ces tables ou (sous certains paramètres de caractéristique de la phrase de réservation) même de lire les données de ces tables pendant que cette transaction est en cours d’exécution.Alternativement, dans cette proposition, vous pouvez spécifier une liste de tables qui peuvent être modifiées par des transactions concurrentes même si une transaction de niveau d’isolation SNAPSHOT TABLE STABILITY est lancée.

Vous pouvez spécifier un nombre arbitraire de tables réservées de la base de données utilisée dans une seule phrase de redondance.

Si l’un des mots-clés SHARED ou PROTECTED est omis, SHARED est supposé.Si la phrase entière FOR est omise, FOR SHARED READ est supposé.Les options de mise en œuvre des réservations de tables par leur nom ne sont pas évidentes.

Table 1. Compatibilité des différents verrouillages
	SHARED READ	SHARED WRITE	PROTECTED READ	PROTECTED WRITE
SHARED READ	oui	oui	oui	oui
SHARED WRITE	oui	oui	non	non
PROTECTED READ	oui	non	oui	non
PROTECTED WRITE	oui	non	non	non

Pour une transaction s’exécutant en mode d’isolation SNAPSHOT pour les tables spécifiées dans la phrase RESERVING, les comportements suivants sont autorisés dans les transactions concurrentes en fonction de leur niveau d’isolation avec différentes méthodes de réservation :

SHARED READ — n’a aucun effet sur l’exécution de transactions concurrentes ;
SHARED WRITE — n’a aucun effet sur le comportement des transactions parallèles avec les niveaux d’isolation SNAPSHOT et READ COMMITTED ; pour les transactions avec le niveau d’isolation SNAPSHOT TABLE STABILITY, il interdit non seulement l’écriture mais aussi la lecture des données des tables spécifiées ;
PROTECTED READ - permet uniquement de lire les données des tables réservées pour les transactions simultanées avec n’importe quel niveau d’isolation ; toute tentative de modification entraîne l’exclusion de la base de données ;
PROTECTED WRITE — pour les transactions parallèles avec les niveaux d’isolation SNAPSHOT et READ COMMITTED, il interdit l’écriture dans les tables spécifiées ; pour les transactions avec le niveau d’isolation SNAPSHOT TABLE STABILITY, il interdit également la lecture des données de la table de réservation.

Pour une transaction démarrée dans le mode d’isolation SNAPSHOT TABLE STABILITY pour les tables spécifiées dans la phrase RESERVING, dans les transactions parallèles, selon leur niveau d’isolation, les variantes de comportement suivantes sont acceptables aux différentes méthodes de leur réservation :

SHARED READ — permet à toutes les transactions concurrentes, quel que soit leur niveau d’isolation, non seulement de lire mais aussi d’effectuer des modifications dans les tables réservées (si la transaction concurrente a le mode d’accès READ WRITE) ;
SHARED WRITE — pour toutes les transactions concurrentes avec le niveau d’accès READ WRITE et avec les niveaux d’isolation SNAPSHOT et READ COMMITTED, il permet de lire les données des tables et d’écrire les données dans les tables spécifiées ; pour les transactions avec le niveau d’isolation SNAPSHOT TABLE STABILITY, il interdit non seulement d’écrire mais aussi de lire les données des tables spécifiées ;
PROTECTED READ - permet de lire uniquement les données des tables réservées pour les transactions parallèles avec n’importe quel niveau d’isolation ;
PROTECTED WRITE — pour les transactions parallèles avec le niveau d’isolation SNAPSHOT et READ COMMITTED, il interdit l’écriture dans les tables spécifiées ; pour les transactions avec le niveau d’isolation SNAPSHOT TABLE STABILITY, il interdit également la lecture des données des tables de réservation.

Pour une transaction démarrée dans le mode d’isolation READ COMMITTED pour les tables spécifiées dans la phrase RESERVING, dans les transactions parallèles, en fonction de leur niveau d’isolation, les variantes de comportement suivantes sont acceptables aux différentes méthodes de leur réservation :

SHARED READ — permet à toutes les transactions concurrentes, quel que soit leur niveau d’isolation, non seulement de lire mais aussi d’effectuer toute modification dans les tables réservées (au niveau d’accès READ WRITE) ;
SHARED WRITE — pour toutes les transactions avec le niveau d’accès READ WRITE et avec les niveaux d’isolation SNAPSHOT et READ COMMITTED, il autorise la lecture et l’écriture de données dans les tables spécifiées ; pour les transactions avec le niveau d’isolation SNAPSHOT TABLE STABILITY, il interdit non seulement l’écriture mais aussi la lecture de données depuis les tables spécifiées ;
PROTECTED READ — permet seulement de lire les données des tables réservées pour les transactions parallèles avec n’importe quel niveau d’isolation ;
PROTECTED WRITE — pour les transactions parallèles avec les niveaux d’isolation SNAPSHOT et READ COMMITTED, permet uniquement la lecture des données et interdit l’écriture dans les tables spécifiées dans cette liste ; pour les transactions avec le niveau d’isolation SNAPSHOT TABLE STABILITY, il interdit non seulement la modification des données mais aussi la lecture des données des tables de réservation.

Tip	La proposition `USING` peut être utilisée pour économiser les ressources du système en limitant le nombre de bases de données auxquelles une transaction peut accéder. Disponible uniquement dans Embedded SQL.

Voir aussi :

COMMIT, ROLLBACK.

`COMMIT`

affectation

Confirmation de la transaction.

Disponible en

DSQL, ESQL

Syntaxe

COMMIT [WORK] [TRANSACTION tr_name]
  [RELEASE] [RETAIN [SNAPSHOT]];

Table 1. Paramètres de l’opérateur `COMMIT`
Paramètre	Description
tr_name	Nom de la transaction. Disponible uniquement dans ESQL.

L’instruction COMMIT confirme toutes les modifications de données effectuées dans le cadre de cette transaction (ajouts, modifications, suppressions). Les nouvelles versions des enregistrements deviennent disponibles pour les autres transactions, et si la clause RETAIN n’est pas utilisée, toutes les ressources du serveur associées à l’exécution de cette transaction sont libérées.

Si une erreur de base de données se produit au cours du processus de validation de la transaction, celle-ci n’est pas validée. Le programme utilisateur doit gérer la situation d’erreur et revalider la transaction ou l’annuler.

La clause optionnelle TRANSACTION spécifie le nom de la transaction. La clause TRANSACTION n’est disponible que dans Embedded SQL. Si la clause TRANSACTION n’est pas spécifiée, l’instruction COMMIT est appliquée à la transaction par défaut.

Note	Les transactions nommées permettent d’exécuter simultanément plusieurs transactions actives dans la même application. Une variable du langage de base portant le même nom doit être déclarée et initialisée. En DSQL, cette restriction empêche la spécification dynamique des noms de transaction.

Le mot-clé facultatif WORK ne peut être utilisé que pour des raisons de compatibilité avec d’autres systèmes de gestion de bases de données relationnelles.

Le mot-clé RELEASE n’est disponible que dans Embedded SQL. Il vous permet de vous déconnecter de toutes les bases de données après la fin de la transaction en cours. Le mot-clé RELEASE n’est supporté que pour des raisons de compatibilité avec les anciennes versions d’Interbase. L’instruction ESQL DISCONNECT est maintenant utilisée à la place.

Si la phrase RETAIN [SNAPSHOT] est utilisée, une validation douce est effectuée. Les actions effectuées dans le cadre de cette transaction sont validées dans la base de données et la transaction elle-même reste active, conservant son identifiant ainsi que l’état du curseur qu’elle avait avant la validation douce. Dans ce cas, il n’est pas nécessaire de relancer la transaction et de réexécuter l’instruction SELECT pour récupérer les données.

Si le niveau d’isolation SNAPSHOT ou SNAPSHOT TABLE STABILITY d’une telle transaction, après le soft commit, la transaction continue à voir l’état de la base de données qui était au début de la transaction, c’est-à-dire que le programme client ne voit pas les résultats nouvellement confirmés de la modification des données d’autres transactions. De plus, le soft commit ne libère pas les ressources du serveur (les curseurs ouverts ne sont pas fermés).

Tip	Pour les transactions qui ne font que lire des données dans la base de données, il est également recommandé d’utiliser l’opérateur `COMMIT` plutôt que `ROLLBACK`, car cette option nécessite moins de ressources serveur et améliore les performances de toutes les transactions suivantes.

Voir aussi :

SET TRANSACTION, ROLLBACK.

`ROLLBACK`

affectation

Annulez la transaction.

Disponible en

DSQL, ESQL

Syntaxe

ROLLBACK [WORK] [TRANSACTION tr_name]
  [RETAIN [SNAPSHOT] | TO SAVEPOINT sp_name] [RELEASE];

Table 1. Paramètres de l’opérateur `ROLLBACK`
Paramètre	Description
tr_name	Nom de la transaction. Disponible uniquement dans ESQL.
sp_name	Le nom du point de sauvegarde, disponible uniquement dans DSQL.

L’instruction ROLLBACK annule tous les changements de données de la base de données (ajouts, modifications, suppressions) effectués dans le contexte de cette transaction. L’instruction ROLLBACK ne provoque jamais d’erreurs. Si l’instruction RETAIN n’est pas spécifiée, elle libère toutes les ressources du serveur associées à l’exécution de cette transaction.

La clause optionnelle TRANSACTION spécifie le nom de la transaction. La clause TRANSACTION n’est disponible que dans Embedded SQL. Si la clause TRANSACTION n’est pas spécifiée, l’instruction ROLLBACK s’applique à la transaction par défaut.

Note	Les transactions nommées permettent à plusieurs transactions actives de s’exécuter simultanément dans la même application. Une variable du langage de base portant le même nom doit être déclarée et initialisée. En DSQL, cette restriction empêche la spécification dynamique des noms de transaction.

Le mot-clé facultatif WORK ne peut être utilisé que pour des raisons de compatibilité avec d’autres systèmes de gestion de bases de données relationnelles.

Le mot-clé RETAIN indique que toutes les actions de modification des données dans le contexte de cette transaction sont annulées et que la transaction elle-même continue d’être active, conservant son identifiant ainsi que l’état du curseur qu’elle avait avant que la transaction ne soit soft-committed. Ainsi, les ressources allouées à la transaction ne sont pas libérées.

Pour les niveaux d’isolation SNAPSHOT et SNAPSHOT TABLE STABILITY, l’état de la base de données reste tel qu’il était lorsque la transaction a été initialement lancée, mais dans le cas du niveau d’isolation READ COMMITTED, la base de données sera telle qu’elle était lorsque l’instruction ROLLBACK RETAIN a été exécutée. Si une transaction est annulée tout en conservant son contexte, il n’est pas nécessaire de réexécuter l’instruction SELECT pour récupérer les données de la table.

Voir aussi :

SET TRANSACTION, COMMIT.

`ROLLBACK TO SAVEPOINT`

La clause optionnelle TO SAVEPOINT de l’instruction ROLLBACK spécifie le nom du point de sauvegarde vers lequel le rollback se produit.Dans ce cas, toutes les modifications effectuées dans la transaction à partir du point de sauvegarde créé (SAVEPOINT) sont annulées.

L’opérateur ROLLBACK TO SAVEPOINT effectue les opérations suivantes :

Toutes les modifications de la base de données effectuées dans la transaction à partir du point de sauvegarde créé sont annulées. Les variables utilisateur définies avec RDB$SET_CONTEXT() restent inchangées ;
Tous les points de sauvegarde créés après le point de sauvegarde nommé sont détruits. Tous les points de sauvegarde antérieurs, comme le point de sauvegarde lui-même, sont conservés. Cela signifie qu’il est possible de revenir plusieurs fois au même point de sauvegarde ;
Tous les enregistrements verrouillés explicites et implicites du point de sauvegarde sont libérés. Les autres transactions qui ont précédemment demandé l’accès aux lignes verrouillées après le point de sauvegarde doivent continuer à attendre jusqu’à ce que la transaction soit validée ou annulée. D’autres transactions qui n’ont pas encore demandé l’accès à ces rangées peuvent demander et accéder immédiatement aux rangées déverrouillées.

Voir aussi :

SAVEPOINT.

`SAVEPOINT`

affectation

Création d’un point de sauvegarde.

Disponible en

DSQL

Syntaxe

SAVEPOINT sp_name

Table 1. Paramètres de l’opérateur `SAVEPOINT`
Paramètre	Description
sp_name	Nom du point de sauvegarde, qui doit être unique dans la transaction.

L’instruction SAVEPOINT crée un point de sauvegarde compatible avec SQL:99 auquel les opérations de la base de données peuvent être ramenées ultérieurement sans annuler les actions effectuées depuis le début de la transaction. Les mécanismes de point de sauvegarde sont également connus sous le nom de transactions imbriquées.

Si un nom de point de sauvegarde existe déjà dans une transaction, le point de sauvegarde existant sera supprimé et un nouveau sera créé avec le même nom.

Pour annuler les modifications apportées au point de sauvegarde, on utilise l’opérateur ROLLBACK TO SAVEPOINT.

Note

Le mécanisme de point de sauvegarde interne peut utiliser de grandes quantités de mémoire, surtout si vous mettez à jour les mêmes enregistrements plusieurs fois dans la même transaction. Si un point de sauvegarde n’est plus nécessaire, mais que vous n’êtes pas encore prêt à terminer la transaction, vous pouvez le supprimer avec l’opérateur RELEASE SAVEPOINT, libérant ainsi des ressources.

Example 1. DSQL session utilisant des points de sauvegarde

CREATE TABLE TEST (ID INTEGER);
COMMIT;
INSERT INTO TEST VALUES (1);
COMMIT;
INSERT INTO TEST VALUES (2);
SAVEPOINT Y;
DELETE FROM TEST;
SELECT * FROM TEST; -- renvoie une chaîne vide
ROLLBACK TO Y;
SELECT * FROM TEST; -- renvoie deux lignes
ROLLBACK;
SELECT * FROM TEST; -- renvoie une seule ligne

Voir aussi :

ROLLBACK TO SAVEPOINT, RELEASE SAVEPOINT.

RELEASE SAVEPOINT

affectation

Suppression d’un point de sauvegarde.

Disponible en

DSQL

Syntaxe

RELEASE SAVEPOINT sp_name [ONLY]

Table 1. Paramètres de l’opérateur `RELEASE SAVEPOINT`
Paramètre	Description
sp_name	Le nom du point de sauvegarde.

L’instruction RELEASE SAVEPOINT supprime le point de sauvegarde nommé, libérant toutes les ressources associées. Par défaut, tous les points de sauvegarde créés après celui spécifié sont également supprimés. Si la clause ONLY est spécifiée, seul le point de sauvegarde portant le nom spécifié est supprimé.

Voir aussi :

SAVEPOINT.

Points de sauvegarde internes

Par défaut, le serveur utilise un point de sauvegarde automatique au niveau de la transaction pour annuler la transaction. Lorsque l’instruction ROLLBACK est exécutée, toutes les modifications apportées à la transaction sont annulées au point de sauvegarde du système, puis la transaction est approuvée.

Lorsque le nombre de modifications effectuées sous le point de sauvegarde au niveau de la transaction devient important (environ 50 000 enregistrements sont concernés), le serveur libère le point de sauvegarde système et utilise le mécanisme TIP pour annuler la transaction si nécessaire.

Tip

Si vous vous attendez à ce que le volume des changements dans une transaction soit important, vous pouvez définir l’option NO AUTO UNDO dans l’instruction SET TRANSACTION, ou — si vous utilisez l’API — définir l’indicateur TPB isc_tpb_no_auto_undo. Les deux options empêchent la création d’un point de transaction de niveau sauvegarde système.

Points de sauvegarde et PSQL

L’utilisation d’instructions de contrôle de transaction dans PSQL n’est pas autorisée car elle romprait l’atomicité de l’instruction appelant la procédure.Mais Firebird supporte l’appel et la gestion des exceptions dans PSQL, de sorte que les actions effectuées dans les procédures stockées et les triggers peuvent être annulées de manière sélective sans annuler complètement toutes les actions qu’ils contiennent.En interne, les points de sauvegarde automatique sont utilisés pour :

Annuler toutes les actions à l’intérieur du `BEGIN … END' où une exception se produit ;
Annuler toutes les actions effectuées dans une procédure stockée ou un déclencheur (ou, dans le cas d’une procédure stockée sélective, toutes les actions effectuées depuis la dernière instruction SUSPEND) si elles se terminent prématurément à cause d’une erreur ou d’une exception involontaire.

Chaque bloc de traitement des exceptions PSQL est également limité aux points de sauvegarde automatique du serveur.

Note	Le bouton "DEBUT … END` ne crée pas de point de sauvegarde automatique. Il est seulement créé dans les blocs qui ont un bloc `WHEN` pour gérer les exceptions ou les erreurs.