Une méthode de récupération doit-elle retourner «null» ou lever une exception lorsqu'elle ne peut pas produire la valeur de retour? [fermé]


503

J'ai une méthode qui est censée retourner un objet s'il est trouvé.

S'il n'est pas trouvé, dois-je:

  1. return null
  2. jeter une exception
  3. autre

57
Quoi que vous fassiez, assurez-vous de le documenter. Je pense que ce point est plus important qu'exactement quelle approche est "la meilleure".
Rik

6
Cela dépend des idiomes dominants du langage de programmation. Veuillez baliser cette question avec une balise de langage de programmation.
Teddy

3
Renvoyer null peut seulement signifier un succès ou un échec qui, très souvent, ne représente pas beaucoup d'informations (certaines méthodes peuvent échouer de plusieurs façons). Les bibliothèques devraient mieux lever des exceptions pour rendre les erreurs explicites et de cette façon, le programme principal peut décider comment gérer l'erreur à un niveau supérieur (contrairement à la logique de gestion des erreurs intégrée).
3k-

1
Il me semble que la vraie question qui se pose est de savoir si nous devons considérer comme exceptionnel qu'une entité ne soit pas trouvée, et si oui, pourquoi? Personne n'a vraiment répondu suffisamment à la façon de parvenir à cette conclusion, et maintenant le Q & A est clos. Dommage que l'industrie ne soit pas parvenue à un consensus sur ce sujet important. Oui, je sais que ça dépend . Alors, expliquez pourquoi cela dépend de plus que "si exceptionnel, jetez"
écraser

Réponses:


484

Si vous vous attendez toujours à trouver une valeur, lancez l'exception si elle est manquante. L'exception signifierait qu'il y avait un problème.

Si la valeur peut être manquante ou présente et que les deux sont valides pour la logique d'application, retournez une valeur nulle.

Plus important: que faites-vous à d'autres endroits du code? La cohérence est importante.


30
@Ken: +1, il serait bon de mentionner que si vous lancez une exception, mais pouvez la détecter a priori (comme HasItem (...)), alors l'utilisateur doit fournir ladite méthode Has * ou Contains.
user7116

4
Au lieu de renvoyer une valeur ou null lorsque la valeur est manquante, pensez à renvoyer un peut-être <T>. Voir mikehadlow.blogspot.nl/2011/01/monads-in-c-5-maybe.html .
Erwin Rooijakkers

2
D'une manière @ErwinRooijakkers design choix , à partir de Java 8, vous pouvez également retourner un <T> facultatif
José Andias

2
Je trouve cela un peu dérangeant chaque réponse fait écho au même proverbe: "Si c'est exceptionnel, jetez." La plupart des ingénieurs vont connaître ce principe. À mon avis, la vraie question ici est de savoir si elle doit être considérée comme exceptionnelle. L'OP recherche la meilleure pratique en ce qui concerne quelque chose comme un modèle de référentiel par exemple. Est-il généralement considéré comme exceptionnel qu'un objet n'existe pas étant donné une clé primaire? Oui, c'est quelque chose que son domaine déterminera, mais que suggèrent la plupart des experts ayant des années d'expérience? C'est le type de réponse que nous devrions voir.
écraser

4
@crush Je pense qu'un principe directeur est quels paramètres sont passés à la fonction . Si vous transmettez une identité , comme vous mentionnez une clé primaire, elle doit être considérée comme exceptionnelle si cet élément n'est pas trouvé, car il indique un état incohérent dans le système. Exemple: GetPersonById(25)lancerait si cette personne a été supprimée, mais GetPeopleByHairColor("red")retournerait un résultat vide. Donc, je pense que les paramètres disent quelque chose sur les attentes.
John Knoop

98

Ne lancez une exception que si c'est vraiment une erreur. S'il est prévu que l'objet n'existe pas, renvoyez la valeur null.

Sinon, c'est une question de préférence.


4
Je ne suis pas d'accord. Vous pouvez lever des exceptions sous forme de codes d'état: "NotFoundException"
ACV

Cela ne devrait certainement pas être une question de préférence. C'est ainsi que nous nous retrouvons avec du code incohérent - sinon dans le code de votre équipe, alors presque certainement lorsque vous entrelacez le code d'autres développeurs avec le vôtre (bibliothèques externes).
écraser

4
Je pense que la gestion du cas nul est beaucoup plus facile que "NotFoundException". Pensez au nombre de lignes de try-catch que vous devez écrire autour de chaque demande de retrival qui génère une "NotFoundException" ... C'est pénible de préparer tout ce code à mes yeux.
visc

je voudrais citer Tony Hoare: "Je l'appelle mon erreur d'un milliard de dollars". Je ne retournerais pas null, je lève une exception et la gère correctement, ou retourne un objet vide.
sept

70

En règle générale, si la méthode doit toujours renvoyer un objet, optez pour l'exception. Si vous prévoyez le null occasionnel et que vous souhaitez le gérer d'une certaine manière, optez pour le null.

Quoi que vous fassiez, je déconseille fortement la troisième option: renvoyer une chaîne qui dit "WTF".


Plus un parce que dans le bon vieux temps je l'ai fait plus d'une ou deux fois comme une solution rapide "sale" temporelle ... pas une bonne idée. Surtout si ça va être revu si vous êtes étudiant.
rciafardone

14
J'allais voter contre car les options WTF me semblaient géniales ... mais apparemment j'ai un cœur
swestner

5
jeter le nouveau WtfExcepti😲n
Kamafeather

Je pense qu'il serait utile que cette réponse mentionne les raisons pour lesquelles une méthode retournerait toujours un objet par rapport à "un null occasionnel". Qu'est-ce qui justifie ce type de situation? Donnez un exemple d'une telle circonstance.
écraser

51

Si null n'indique jamais une erreur, retournez simplement null.

Si null est toujours une erreur, lancez une exception.

Si null est parfois une exception, codez deux routines. Une routine lève une exception et l'autre est une routine de test booléenne qui renvoie l'objet dans un paramètre de sortie et la routine renvoie un faux si l'objet n'a pas été trouvé.

Il est difficile d'abuser d'une routine Try. Il est très facile d'oublier de vérifier la valeur null.

Donc, lorsque null est une erreur, vous écrivez simplement

object o = FindObject();

Lorsque le null n'est pas une erreur, vous pouvez coder quelque chose comme

if (TryFindObject(out object o)
  // Do something with o
else
  // o was not found

1
Ce serait une suggestion plus utile si C # fournissait de vrais tuples, afin que nous puissions éviter d'utiliser un paramètre [out]. Pourtant, c'est le modèle préféré, donc +1.
Erik Forbes

2
À mon avis, l'approche d'essai est la meilleure. Vous n'avez pas à rechercher alors ce qui se passe si l'objet ne peut pas être retourné. Avec une méthode Try, vous savez immédiatement quoi faire.
OregonGhost

me rappelle le findet findOrFailde Laravel Eloquent
vivoconunxino

@ErikForbes Je sais que votre commentaire est ancien, mais la réponse n'aurait-elle pas été de définir un objet multi-propriétés qui serait renvoyé par la TryFindObjectméthode? Les tuples semblent plus un paradigme paresseux pour les programmeurs qui ne veulent pas prendre le temps de définir un objet qui encapsule plusieurs valeurs. C'est essentiellement tous les tuples sont de toute façon au cœur.
écraser

@crush - Les littéraux de tuple nommés sont une option, OMI. Il s'agit d'un lien vers un modèle asynchrone Try Get avec des tuples. stackoverflow.com/questions/1626597/…
ttugates

26

Je voulais juste récapituler les options mentionnées précédemment, en en ajoutant de nouvelles:

  1. return null
  2. lever une exception
  3. utiliser le modèle d'objet nul
  4. fournir un paramètre booléen à votre méthode, afin que l'appelant puisse choisir s'il veut que vous leviez une exception
  5. fournir un paramètre supplémentaire, afin que l'appelant puisse définir une valeur qu'il récupère si aucune valeur n'est trouvée

Ou vous pouvez combiner ces options:

Fournissez plusieurs versions surchargées de votre getter, afin que l'appelant puisse décider de la direction à suivre. Dans la plupart des cas, seul le premier a une implémentation de l'algorithme de recherche, et les autres enveloppent simplement le premier:

Object findObjectOrNull(String key);
Object findObjectOrThrow(String key) throws SomeException;
Object findObjectOrCreate(String key, SomeClass dataNeededToCreateNewObject);
Object findObjectOrDefault(String key, Object defaultReturnValue);

Même si vous choisissez de ne fournir qu'une seule implémentation, vous souhaiterez peut-être utiliser une convention de dénomination comme celle-ci pour clarifier votre contrat, et cela vous aidera si vous décidez d'ajouter d'autres implémentations.

Vous ne devriez pas en abuser, mais cela peut être utile, surtout lorsque vous écrivez une classe d'assistance que vous utiliserez dans des centaines d'applications différentes avec de nombreuses conventions de gestion des erreurs.


J'aime les noms de fonction clairs, en particulier orCreate et orDefault.
marcovtwout

5
La plupart de ce qui peut être plus proprement écrit avec Expected<T> findObject(String)Expected<T>a les fonctions orNull(), orThrow(), orSupplied(Supplier<T> supplier), orDefault(T default). Ceci résume l'obtention des données de la gestion des erreurs
WorldSEnder

Je ne connaissais pas <T> attendu jusqu'à présent. Je semble être assez nouveau et je n'aurais peut-être pas existé lorsque j'ai écrit la réponse originale. Vous devriez peut-être faire de votre commentaire une réponse appropriée.
Lena Schimmel

En outre, <T> attendu est un modèle C ++. Existe-t-il également des implémentations dans d'autres langages orientés objet?
Lena Schimmel

Dans Java 8, le retour facultatif de <T> (appelé peut-être <T>, etc. dans d'autres langues) est également une option. Cela indique clairement à l'appelant que ne rien renvoyer est une possibilité et ne se compilera pas si l'appelant n'a pas géré cette possibilité, par opposition à null, qui (en Java de toute façon) compilera même si l'appelant ne la vérifie pas. .
Some Guy

18

Utilisez le modèle d'objet nul ou lève une exception.


Telle est la vraie réponse. Renvoyer null est une terrible habitude des programmeurs paresseux.
jeremyjjbrown

Je ne peux pas croire que cette réponse n'ait pas encore été votée en haut. C'est la vraie réponse, et l'une ou l'autre approche est extrêmement simple et permet d'économiser beaucoup de code bloat ou de NPE.
Bane


3
Si l'on utilise le modèle d'objet nul, comment distinguer le cas où la clé est mappée à l'objet nul du cas où la clé n'a pas de mappage? Je pense que retourner un objet vide de sens serait bien pire que de retourner null. Retourner null à du code qui n'est pas prêt à le gérer entraînera généralement la levée d'une exception. Pas le choix d'exception optimal, mais une exception néanmoins. Renvoyer un objet dépourvu de sens est plus susceptible d'entraîner un code incorrect considérant les données dépourvues de sens comme correctes.
supercat

3
Comment l'objet nul se comporterait-il lors d'une recherche d'entité? Par exemple, Person somePerson = personRepository.find("does-not-exist");supposons que cette méthode renvoie un objet nul pour l'ID does-not-exist. Quel serait alors le comportement correct somePerson.getAge()? Pour l'instant, je ne suis pas encore convaincu que le modèle d'objet nul soit la bonne solution pour les recherches d'entités.
Abdull

13

Soyez cohérent avec les API que vous utilisez.


13

Avantages de lever une exception:

  1. Flux de contrôle plus propre dans votre code d'appel. La vérification de null injecte une branche conditionnelle qui est gérée nativement par try / catch. La vérification de null n'indique pas ce que vous recherchez - vérifiez-vous pour null parce que vous recherchez une erreur que vous attendez, ou vérifiez-vous pour que vous ne la transmettiez pas plus loin sur la chaîne descendante ?
  2. Supprime l'ambiguïté de ce que signifie "null". Null est-il représentatif d'une erreur ou est-il nul ce qui est réellement stocké dans la valeur? Difficile à dire quand vous n'avez qu'une seule chose sur laquelle baser cette détermination.
  3. Amélioration de la cohérence entre le comportement des méthodes dans une application. Les exceptions sont généralement exposées dans les signatures de méthode, ce qui vous permet de mieux comprendre à quels cas marginaux les méthodes d'une compte d'application et à quelles informations votre application peut réagir de manière prévisible.

Pour plus d'explications avec des exemples, voir: http://metatations.com/2011/11/17/returning-null-vs-throwing-an-exception/


2
+1 parce que le point 2 est excellent - null n'a pas la même signification que introuvable. Cela devient plus important lorsqu'il s'agit de langages dynamiques où Null pourrait en fait être l'objet stocké / récupéré par la fonction - et dans ce cas
Adam Terrey

1
+1 pour le point # 2. Null est-il une erreur? Est nul ce qui est stocké pour la clé donnée? La valeur null indique-t-elle que la clé n'existe pas? Ce sont les vraies questions qui indiquent clairement que retourner null n'est presque jamais correct. C'est probablement la meilleure réponse ici, car tout le monde vient de lancer l'ambiguë "Si c'est exceptionnel, lancez"
écraser

12

cela dépend si votre langue et votre code favorisent: LBYL (regardez avant de sauter) ou EAFP (plus facile de demander pardon que de permission)

LBYL dit que vous devriez vérifier les valeurs (donc retournez une valeur nulle)
EAFP dit d'essayer simplement l'opération et de voir si elle échoue (lever une exception)

bien que je sois d'accord avec ce qui précède .. les exceptions doivent être utilisées pour des conditions exceptionnelles / d'erreur, et retourner un null est préférable lorsque vous utilisez des chèques.


EAFP vs LBYL en Python:
http://mail.python.org/pipermail/python-list/2003-May/205182.html ( Web Archive )


3
Dans certains cas, l'EAFP est la seule approche valable. Dans une carte / dictionnaire simultanée, par exemple, il n'y a aucun moyen de demander si une cartographie existera lorsqu'elle sera demandée.
supercat

11

Demandez-vous simplement: "est-ce un cas exceptionnel que l'objet ne soit pas retrouvé"? Si cela devrait se produire dans le cours normal de votre programme, vous ne devriez probablement pas lever une exception (car ce n'est pas un comportement exceptionnel).

Version courte: utilisez des exceptions pour gérer un comportement exceptionnel, pas pour gérer le flux normal de contrôle dans votre programme.

-Alan.


5

Les exceptions sont liées à la conception par contrat.

L'interface d'un objet est en fait un contrat entre deux objets, l'appelant doit respecter le contrat ou bien le récepteur peut simplement échouer avec une exception. Il existe deux contrats possibles

1) toutes les entrées de la méthode sont valides, auquel cas vous devez retourner null lorsque l'objet n'est pas trouvé.

2) seule une entrée est valide, c'est-à-dire celle qui aboutit à un objet trouvé. Dans ce cas, vous DEVEZ proposer une seconde méthode qui permet à l'appelant de déterminer si son entrée sera correcte. Par exemple

is_present(key)
find(key) throws Exception

SI et UNIQUEMENT SI vous fournissez les deux méthodes du 2e contrat, vous êtes autorisé à lever une exception si rien n'est trouvé!


4

Je préfère simplement renvoyer une valeur nulle et compter sur l'appelant pour le gérer correctement. L'exception (faute d'un meilleur mot) est que si je suis absolument «certain», cette méthode retournera un objet. Dans ce cas, un échec est une exception et devrait être lancé.


4

Dépend de ce que cela signifie que l'objet n'est pas trouvé.

Si c'est une situation normale, retournez null. C'est juste quelque chose qui peut arriver de temps en temps, et les appelants doivent le vérifier.

S'il s'agit d'une erreur, puis lancez une exception, les appelants doivent décider quoi faire avec la condition d'erreur de l'objet manquant.

En fin de compte, l'un ou l'autre fonctionnerait, bien que la plupart des gens considèrent généralement comme une bonne pratique de n'utiliser les exceptions que lorsque quelque chose, enfin, exceptionnel s'est produit.


2
Comment expliqueriez-vous l' énoncé de "l' état normal des choses " et quels critères utiliserez-vous pour le distinguer d'une erreur?
user1451111

4

Voici quelques suggestions supplémentaires.

Si vous retournez une collection, évitez de renvoyer null, renvoyez une collection vide, ce qui facilite le traitement de l'énumération sans vérification null.

Plusieurs API .NET utilisent le modèle d'un paramètre thrownOnError qui donne à l'appelant le choix s'il s'agit vraiment d'une situation exceptionnelle ou non si l'objet n'est pas trouvé. Type.GetType en est un exemple. Un autre modèle courant avec BCL est le modèle TryGet où un booléen est renvoyé et la valeur est transmise via un paramètre de sortie.

Vous pouvez également prendre en compte le modèle Null Object dans certaines circonstances, qui peut être une valeur par défaut ou une version sans comportement. La clé est d'éviter les contrôles nuls dans toute la base de code. Voir ici pour plus d'informations http://geekswithblogs.net/dsellers/archive/2006/09/08/90656.aspx


3

Dans certaines fonctions, j'ajoute un paramètre:

..., bool verify = true)

True signifie throw, false signifie return some error return value. De cette façon, quiconque utilise cette fonction a les deux options. La valeur par défaut doit être vraie, pour le bénéfice de ceux qui oublient la gestion des erreurs.


3

Renvoyer une valeur null au lieu de lever une exception et documenter clairement la possibilité d'une valeur de retour nulle dans la documentation de l'API. Si le code appelant n'honore pas l'API et ne vérifie pas le cas nul, cela entraînera très probablement une sorte d '"exception de pointeur nul" :)

En C ++, je peux penser à 3 saveurs différentes de la mise en place d'une méthode qui trouve un objet.

Option A

Object *findObject(Key &key);

Renvoie null lorsqu'un objet est introuvable. Agréable et simple. J'irais avec celui-ci. Les approches alternatives ci-dessous sont destinées aux personnes qui ne détestent pas les paramédicaux.

Option B

void findObject(Key &key, Object &found);

Passez une référence à la variable qui recevra l'objet. La méthode a levé une exception lorsqu'un objet est introuvable. Cette convention est probablement plus appropriée si l'on ne s'attend pas vraiment à ce qu'un objet ne soit pas trouvé - par conséquent, vous lancez une exception pour signifier qu'il s'agit d'un cas inattendu.

Option C

bool findObject(Key &key, Object &found);

La méthode renvoie false lorsqu'un objet est introuvable. L'avantage de cette option A est que vous pouvez vérifier le cas d'erreur en une seule étape claire:

if (!findObject(myKey, myObj)) { ...

3

se référant uniquement au cas où null n'est pas considéré comme un comportement exceptionnel, je suis définitivement pour la méthode try, il est clair, pas besoin de "lire le livre" ou de "regarder avant de sauter" comme cela a été dit ici

donc en gros:

bool TryFindObject(RequestParam request, out ResponseParam response)

et cela signifie que le code de l'utilisateur sera également clair

...
if(TryFindObject(request, out response)
{
  handleSuccess(response)
}
else
{
  handleFailure()
}
...

2

S'il est important que le code client connaisse la différence entre trouvé et introuvable et que cela est censé être un comportement de routine, il est préférable de renvoyer null. Le code client peut alors décider quoi faire.


2

En général, il doit retourner null. Le code appelant la méthode doit décider de lever une exception ou de tenter autre chose.


2

Ou retourner une option

Une option est essentiellement une classe de conteneur qui oblige le client à gérer les cas de cabine. Scala a ce concept, recherchez son API.

Ensuite, vous avez des méthodes comme T getOrElse (T valueIfNull) sur cet objet qui retournent soit l'objet trouvé, soit une alternative que le client spécifie.


2

Je préfère retourner null -

Si l'appelant l'utilise sans vérifier, l'exception se produit de toute façon.

Si l'appelant ne l'utilise pas vraiment, ne le taxez pas a try/ catchblock


2

Malheureusement, JDK est incohérent, si vous essayez d'accéder à une clé non existante dans un ensemble de ressources, vous ne recevez pas d'exception et lorsque vous demandez une valeur à la carte, vous obtenez null si elle n'existe pas. Je changerais donc la réponse du gagnant comme suit, si la valeur trouvée peut être nulle, puis déclencher une exception lorsqu'elle n'est pas trouvée, sinon retourner null. Suivez donc la règle avec une exception, si vous avez besoin de savoir pourquoi la valeur n'est pas trouvée, alors toujours lever l'exception, ou ..


1

Tant qu'il est censé renvoyer une référence à l'objet, le retour d'un NULL devrait être bon.

Cependant, si cela retourne tout le sang (comme en C ++ si vous faites: 'return blah;' plutôt que 'return & blah;' (ou 'blah' est un pointeur), alors vous ne pouvez pas retourner un NULL, car c'est pas de type 'objet'. Dans ce cas, lever une exception ou retourner un objet vide qui n'a pas d'indicateur de réussite est la façon dont j'aborderais le problème.


1

Ne pensez pas que quiconque ait mentionné les frais généraux dans la gestion des exceptions - prend des ressources supplémentaires pour charger et traiter l'exception, donc à moins qu'il ne s'agisse d'un véritable arrêt de l'application ou d'un arrêt de processus (aller de l'avant causerait plus de mal que de bien), j'opterais pour le renvoi d'un valeur que l'environnement appelant pourrait interpréter comme bon lui semble.


1

Je suis d'accord avec ce qui semble être le consensus ici (retourner null si "non trouvé" est un résultat normal possible, ou lever une exception si la sémantique de la situation nécessite que l'objet soit toujours trouvé).

Il existe cependant une troisième possibilité qui pourrait avoir un sens en fonction de votre situation particulière. Votre méthode peut renvoyer un objet par défaut d'une certaine sorte dans la condition "non trouvé", permettant au code appelant d'être assuré qu'il recevra toujours un objet valide sans avoir besoin de vérification nulle ou de capture d'exception.


1

Retournez une valeur nulle, les exceptions sont exactement cela: quelque chose que votre code fait qui n'est pas prévu.



1

Si la méthode renvoie une collection, renvoyez une collection vide (comme indiqué ci-dessus). Mais s'il vous plaît, pas Collections.EMPTY_LIST ou autre! (en cas de Java)

Si la méthode récupère un seul objet, alors vous avez quelques options.

  1. Si la méthode doit toujours trouver le résultat et que c'est un vrai cas d'exception pour ne pas trouver l'objet, alors vous devez lever une exception (en Java: veuillez une exception non vérifiée)
  2. (Java uniquement) Si vous pouvez tolérer que la méthode lève une exception vérifiée, lâchez une exception ObjectNotFoundException spécifique à un projet ou similaire. Dans ce cas, le compilateur vous dit si vous oubliez de gérer l'exception. (Ceci est ma gestion préférée des choses non trouvées en Java.)
  3. Si vous dites que c'est vraiment ok, si l'objet n'est pas trouvé et que le nom de votre méthode est comme findBookForAuthorOrReturnNull (..), alors vous pouvez retourner null. Dans ce cas, il est fortement recommandé d'utiliser une sorte de vérification statique ou de vérification du compilateur, ce qui empêche le déréférencement du résultat sans vérification nulle. Dans le cas de Java, cela peut être par exemple. FindBugs (voir DefaultAnnotation sur http://findbugs.sourceforge.net/manual/annotations.html ) ou IntelliJ-Checking.

Soyez prudent, si vous décidez de retourner un null. Si vous n'êtes pas le seul programmeur dans le projet, vous obtiendrez NullPointerExceptions (en Java ou autre dans d'autres langues) au moment de l'exécution! Ne retournez donc pas de valeurs nulles qui ne sont pas vérifiées au moment de la compilation.


Pas si le code a été correctement écrit pour s'y attendre null. Voir la réponse la plus votée pour en savoir plus.
Andrew Barber

Mais seulement si vous vous assurez au moment de la compilation que toutes les valeurs nulles sont vérifiées. Cela peut être fait en utilisant FindBugs @NutNull au niveau du package et marquez votre méthode comme "peut retourner null". Ou pour utiliser une langue comme Kotlin ou Nice. Mais il est beaucoup plus simple de ne pas retourner null.
iuzuz

"Plus simple", peut - être . Mais souvent tout simplement incorrect
Andrew Barber

1
Encore une fois: lisez la réponse la plus votée pour plus d'informations. Fondamentalement: s'il est un résultat potentiellement attendu que le livre demandé ne soit pas trouvé, une exception est la mauvaise chose à faire lorsque le livre demandé est tout simplement introuvable, par opposition à une erreur.
Andrew Barber

1
Vous vous méprenez beaucoup ici. Vous appliquez les conseils conditionnels de manière universelle, ce qui est presque toujours une mauvaise chose à faire. Lisez également le reste des réponses votées. Votre réponse énonce simplement un absolu et présente une logique extrêmement défectueuse.
Andrew Barber

1

Si vous utilisez une bibliothèque ou une autre classe qui lève une exception, vous devez la relancer . Voici un exemple. Example2.java est comme une bibliothèque et Example.java utilise son objet. Main.java est un exemple pour gérer cette exception. Vous devez afficher un message significatif et (si nécessaire) une trace de pile à l'utilisateur du côté appelant.

Main.java

public class Main {
public static void main(String[] args) {
    Example example = new Example();

    try {
        Example2 obj = example.doExample();

        if(obj == null){
            System.out.println("Hey object is null!");
        }
    } catch (Exception e) {
        System.out.println("Congratulations, you caught the exception!");
        System.out.println("Here is stack trace:");
        e.printStackTrace();
    }
}
}

Example.java

/**
 * Example.java
 * @author Seval
 * @date 10/22/2014
 */
public class Example {
    /**
     * Returns Example2 object
     * If there is no Example2 object, throws exception
     * 
     * @return obj Example2
     * @throws Exception
     */
    public Example2 doExample() throws Exception {
        try {
            // Get the object
            Example2 obj = new Example2();

            return obj;

        } catch (Exception e) {
            // Log the exception and rethrow
            // Log.logException(e);
            throw e;
        }

    }
}

Example2.java

 /**
 * Example2.java
 * @author Seval
 *
 */
public class Example2 {
    /**
     * Constructor of Example2
     * @throws Exception
     */
    public Example2() throws Exception{
        throw new Exception("Please set the \"obj\"");
    }

}

Si l'exception à lever de la fonction n'est pas une exception d'exécution et que l'appelant est censé la gérer (au lieu de simplement terminer le programme), au lieu de lever une exception à partir d'un sous-système interne auquel l'appelant ne peut pas s'attendre, il serait préférable d'envelopper l'exception interne avec une exception externe vérifiée, tout en «chaînant» l'exception interne afin que quelqu'un qui débogue puisse comprendre pourquoi l'exception externe a été levée. Par exemple, example1 pourrait utiliser 'throw new MyCheckedException ("Veuillez définir \" obj \ "", e)' pour inclure 'e' dans l'exception levée.
Some Guy

0

Cela dépend vraiment si vous vous attendez à trouver l'objet ou non. Si vous suivez l'école de pensée selon laquelle les exceptions doivent être utilisées pour indiquer quelque chose, eh bien, euh, une exception s'est produite alors:

  • Objet trouvé; objet de retour
  • Objet non trouvé; jeter l'exception

Sinon, retournez null.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.