Utiliser des Exception personnalisé, à quoi ça sert ?

Le problème exposé dans ce sujet a été résolu.

Bonjour,

Dans des projets PHP, je vois souvent des class PHP avec 3 lignes pour personnaliser des Exception, mais je me demande à quoi ça sert ? pourquoi ne pas utiliser celle de PHP tout court ?

Par exemple pour le projet php-tmdb, ils utilisent cette Exception :

<?php
namespace Tmdb\Exception;

class JsonDecodingException extends UnexpectedResponseException
{
}

Pourquoi ne pas utiliser l'Exception de PHP ?

Désolé si la question peut paraitre absurde, mais je n’arrive pas à comprendre le concept.

Cordialement

+0 -0

Hello,

En fait c’est hyper utile au moment où tu dois catcher ton exception:

try {
  faireQuelquechoseQuiPourraitLeverUneExceptionJsonDecoding();
} catch (\Tmdb\Exception\JsonDecodingException $exception) {
  // Au cas où l'exception se déclenche je peux gérer l'erreur
}

Et en fait il est possible que ton code trigger d’autres exceptions, ou plus largement des Throwable. Mais quand on utilise un framework par exemple on a un bout de code qui gère toutes les erreurs "non gérées par l’utilisateur". Le framework va donc faire un truc genre:

try {
  executionDeTonCode();
} catch (Throwable $e) {
  // Le framework va afficher ici une erreur un peu plus sympa que celle de PHP de base !
}

Et pour finir perso je fais même des interfaces pour mes librairies comme ça je peux catcher toutes les erreurs d’une librairie en particulier. Un peu comme tu peux voir dans ce code.

Donc en gros, c’est pour ajouter des Exceptions à la liste des Exceptions prédéfinies de PHP, pour gérer les erreurs spécifiques de leurs classes ?

Car JsonDecodingException est une extension de UnexpectedResponseException elle même étendue de la classe RuntimeException.

Mais du coup pourquoi ne pas utiliser RuntimeException directement ? c’est ça que je pige pas.

+0 -0

Pour savoir directement quelle exception tu reçois. Une RuntimeException c’est pas forcément explicite, ça peut correspondre à pas mal de choses.

Alors qu’en faisant catch(JsonDecodingException $exception) tu sais directement que tu gères uniquement les erreurs de décodage JSON, mais pas les autres RuntimeException que tu peux gérer plus loin… ou laisser remonter à volonté.

Donc c’est pour cibler une erreur précise alors ?

Car si je catch une erreur json avec l’exception RuntimeException, ça fonctionnera quand même, non ?

Je commence à comprendre mais ça reste encore assez flou

+0 -0

Oui, c’est pour avoir plus de granularités. Par exemple, pour une méthode faisant appel HTTP vers un service externe, tu pourras lancer une TimeoutException en cas de timeout, une UnauthorizedException en cas de réponse 401 Unauthorized, etc.

En ayant ces différentes exceptions, dans ton code appelant cette méthode, tu peux prendre une décision différente. Peut-être qu’en cas de TimeoutException, tu peux réessayer avant de lancer une erreur à ton utilisateur. En cas de UnauthorizedException, tu peux dire à ton utilisateur que ses identifiants sont incorrects.

Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte