01-03-2015, 03:25 PM
Rien ne t'oblige à try/catcher partout, puisque si une exception est lancée, elle "bouillonne" (ou remonte) jusqu'au bloc try/catch de niveau le plus proche (à défaut, une erreur "uncaught exception" arrive). Donc, si tu as une trace type
{main}→Game:
tart()→GameLoader::load()→GameModel::countPlayer()→add()
Alors tu peux ne try/catcher que dans la partie {main}, le reste du code n'est pas "alourdi".
Sinon, tu peux parfaitement croiser les deux, et appeler une classe d'erreur dans add() qui va ou bien lancer l'exception (ce qui revient à throw/try/catch) ou bien faire autre chose (logger cela comme un warning?).
Mais ce système peut également se faire au niveau du try/catch lui-même: le code planté envoie l'exception, le catch la récupère et la passe à une classe d'erreur, qui décide (suivant le niveau de l'exception) de laisser poursuivre le code, ou bien de relancer une autre exception.
Au fond, l'intérêt du throw est d'offrir à un code appelé un moyen différent du return d'informer le code appelant d'un plantage.
Si tu préfère que le code appelé gère l'erreur lui-même, tu peux effectivement utiliser une classe d'erreur, spécifique au code appelé ou générique: le code appelant s'en fiche de comment ça se passe dans le code appelé
Note que sur des cas plus complexes, le typehinting de PHP (avec un peu de code pour transformer cela en exception évite bien des lourdeurs type if (is_a($argument, "interface")).
{main}→Game:
tart()→GameLoader::load()→GameModel::countPlayer()→add()Alors tu peux ne try/catcher que dans la partie {main}, le reste du code n'est pas "alourdi".
Sinon, tu peux parfaitement croiser les deux, et appeler une classe d'erreur dans add() qui va ou bien lancer l'exception (ce qui revient à throw/try/catch) ou bien faire autre chose (logger cela comme un warning?).
Mais ce système peut également se faire au niveau du try/catch lui-même: le code planté envoie l'exception, le catch la récupère et la passe à une classe d'erreur, qui décide (suivant le niveau de l'exception) de laisser poursuivre le code, ou bien de relancer une autre exception.
Au fond, l'intérêt du throw est d'offrir à un code appelé un moyen différent du return d'informer le code appelant d'un plantage.
Si tu préfère que le code appelé gère l'erreur lui-même, tu peux effectivement utiliser une classe d'erreur, spécifique au code appelé ou générique: le code appelant s'en fiche de comment ça se passe dans le code appelé
Note que sur des cas plus complexes, le typehinting de PHP (avec un peu de code pour transformer cela en exception évite bien des lourdeurs type if (is_a($argument, "interface")).