Lance une exception non définie dans l'interface

Question

Quelle est la meilleure pratique à suivre lorsque vous devez lever une exception qui n'a pas été définie dans une interface que vous implémentez?

Voici un exemple:

public interface Reader 
{ 
    public abstract void read() throws IOException; 
} 

public class CarrotReader implements Reader 
{ 
    public void read() throws IOException {} 
} 

public class CupcakeReader implements Reader 
{ 
    public void read() throws IOException, CupcakeException {} 
} 

Dans ce cas, vous avez une exception qui se produit lors de la lecture des petits gâteaux, de sorte que vous voulez lancer une exception liée à cela. Cependant, Reader ne définit pas ce type d'exception dans son interface, alors que faites-vous? En outre, il n'a pas de sens pour ajouter CupcakeException à l'lancers francs l'interface clause du lecteur, parce que ce type d'exception est spécifique à CupcakeReader. Une façon de contourner cela est d'avoir Reader définir lire de sorte qu'il lève un certain type parent, comme Exception, mais vous perdez le contexte de l'exception. Que devriez-vous faire dans cette situation? Merci!

---

Une autre situation intéressante qui a été soulevée concerne une interface sur laquelle vous n'avez aucun contrôle. Dans ce cas, quelle est la meilleure façon d'indiquer qu'un problème est survenu?

À titre d'illustration, voici un autre exemple:

public interface Reader 
{ 
    public abstract void read(); 
} 

public class CupcakeReader implements Reader 
{ 
    public void read() throws CupcakeException {} 
} 

Dans ce cas, vous ne pouvez pas changer lecteur, mais vous voulez indiquer qu'un problème est survenu dans de CupcakeReader lire méthode.

Answer 1

Vous devrez peut-être créer une exception du type attendu à la place.

... catch(CupcakeException e) { 
    throw new IOException("The sky is falling", e); 
} 

Answer 2

Peut-être pourriez-vous créer une classe ReaderSpecificException abstraite, la placer dans l'interface, et sous-classe CupcakeException de cette classe abstraite.

Answer 3

Utilisez quelque chose appelé ReaderException qui servira d'interface racine de votre hiérarchie d'exception. ReaderException fournit également un lien vers d'autres exceptions renvoyées en raison d'exceptions de niveau inférieur.

Answer 4

Si vous créez une exception abstraite supérieure qui fonctionne comme une classe de base pour CupCakeException vous ne lient pas l'interface lecteur à une implémentation spécifique, comme vous feriez si vous avez ajouté le CupCakeException à l'interface du lecteur. Si vous ne laissez pas une exception hériter d'une autre, il y a un constructor dans la classe d'exception qui prend un second argument comme Thorbjørn Ravn Andersen déjà montré dans son exemple de code court. Cela vous permet de générer une exception plus abstraite et chaque partie de votre code qui doit en savoir plus que "il y a une erreur" peut rechercher la cause de l'exception plus élevée.

Answer 5

N'utilisez simplement pas les exceptions vérifiées.

L'exemple que vous avez montré est l'une des raisons pour lesquelles les exceptions vérifiées sont mauvaises.

La raison principale est que l'utilisateur de votre lecteur cupcake devra gérer votre exception, qu'il s'y intéresse ou non.

Ainsi, au lieu de:

Value value = reader.read(); 

Vous le forçaient à faire:

Value value = null; 
try { 
    value = reader.read(); 
} catch (Exception e) { 
    // now what?? 
} 

value.doSomething(); // potential NPE here 

Pensez que l'on est mieux, plus lisible et moins sujette aux erreurs et juste cesser d'utiliser les exceptions vérifiées.

EDIT:

Je suis surpris par la note négative. Y a-t-il des gens qui pensent encore que les exceptions vérifiées sont bonnes? Si oui, voici quelques références pourquoi vous ne devriez pas utiliser les exceptions cochés:

• Aucun cadre moderne utilise exceptions vérifiées (printemps, EJB3, etc.)
• article avec des exemples de code here
• StackOverflow topic
• efficace Java (sections 58 et 59) - here

Answer 6

L'exception fait partie de l'interface. Définissez un parent générique pour toutes vos exceptions dans l'interface si vous pouvez redéfinir l'interface.

Vous pouvez également faire de CupcakeException un enfant de IOException.