La capture de Java erreurs
J'ai entendu dire que la capture de java.lang.Error
est considéré comme une mauvaise pratique.
Je suis en train de charger un .dll qui n'est pas la garantie d'être sur le CHEMIN, et souhaite passer à un utilisateur l'emplacement configuré dans le cas où il n'est pas.
try {
System.loadLibrary("HelloWorld");
} catch(UnsatisfiedLinkError ule){
System.load("C:/libraries/HelloWorld.dll");
}
Est-il une meilleure manière de faire ceci? Ou est la capture de la UnsatisfiedLinkError
ici acceptable?
- Pas d'idée sur le droit de la convetion ici, mais vous pouvez tester si le fichier existe avant d'essayer...
new File("path/helloworld.dll").exists()
.... (edit: mauvaise suggestion, j'ai mal lu le code) - Je pense qu'il serait une solution acceptable.
- Vous devez rechercher tous les répertoires dans le
java.library.path
- Je suppose que dans ce cas c'est ok. Bien que vous pourriez juste besoin de tester si le fichier extists à l'avance... Mais ce n'est pas si amusant que vous avez à la recherche par le biais de tout le chemin à la main...
- Je ne vois pas de problème avec ça.
Vous devez vous connecter pour publier un commentaire.
Autre que de donner des conseils sur comment techniquement surmonter le problème, je voudrais prendre un moment pour expliquer pourquoi il est considéré comme "mauvaise pratique" en premier lieu.
Commençons par clarifier ce que l'
Error
classe.En java, des erreurs et des exceptions (qui sont les principaux types) sont jetés. En jetant un des ci-dessus est fait en utilisant la
throw
mot-clé. Chaque classe qui étend la basejava.lang.Throwable
peut être levée.Il y a deux classes qui héritent de la base
Throwable
classe:Exception
etError
. La différence entre les deux est expliqué dans leurs documentations:Source
Source
Comme expliqué ci-dessus, les erreurs et les exceptions sont séparés à cause de leurs origines différentes. Un
Error
indique normalement un problème, qui l'application ne peut pas récupérer de. Par conséquent, ils ne devraient pas être pris.Le même est vrai pour une
RuntimeException
, mais il est utilisé pour indiquer un problème avec un haut niveau de la couche (par exemple, les méthodes). Alors que laError
indique un problème de bas niveau (par exemple, le moteur d'exécution).Donc, maintenant que vous avez compris que vous ne seul hic, les exceptions et les erreurs qui vous êtes en mesure de récupérer à partir de, la réponse à votre question doit être claire.
Oui, il est parfaitement raisonnable pour attraper le
UnsatisfiedLinkError
, parce que votre application peut récupérer.J'ai recouvert le dessus (plus en détail et avec des exemples) et des informations importantes dans un l'article sur mon Blog.
RuntimeException
à quelque chose autour de la langue. Encore souhaitent y avait une meilleure façon de le faire.Vous ne devez attraper les Erreurs dans des cas très spécifiques. Seul hic, et de l'erreur si vous avez exploré toutes les autres possibilités. Je suis complètement d'accord avec tout ce que Lukas Knuth a dit. Mais j'ai un petit ajout.
Dans le cas où vous à attraper toute sorte d'erreur, assurez-vous de voir les erreurs que de se limiter à un champ d'application que vous le pouvez. Également, si possible, assurez-vous que les méthodes de capture des erreurs sont déclarées comme final. La raison en est que la capture des Erreurs peuvent généralement conduire à certains très fragile programmes. Considérez que vous attrapez une erreur sur une méthode qui est étendu par la suite à en appeler d'autres méthodes, toutes ces méthodes serait désormais également avoir des erreurs pris (involontairement) par le sus-jacente de l'attraper.
Si vous avez besoin de rattraper une Erreur, de le faire dans un étroit, contrôlée de fasion.
appels loadLibrary findLibrary() qui serait utile, mais il est protégé, votre meilleur pari est d'écrire votre propre classe de l'extension de chargeur de classe. Chargeur de classe a une méthode protégée appelée findLibrary() qui renvoie le chemin d'accès à une bibliothèque ou null si il n'existe pas. De cette façon, vous pouvez simplement vérifier la valeur null au lieu de la capture des erreurs. Je ne suis pas sûr si ce est en fait "mieux" mais il va supprimer vos besoin pour essayer de l'attraper;
Si vous êtes le codage de manière défensive et peut récupérer à partir d'une question, ce n'est pas un Java
Error
. Si une telle question n'est pas très probable, puis de créer une sous-classe deException
et à lancer et à attraper que. Si une telle question est probable, alors il ne devrait même pas jeter unException
; mais, devrait faire partie de l'ordinaire flux de code.Errors
sont fait l'un pour vraiment mauvais échecs, pas récupérables "échecs" qui ne le sont pas vraiment, même les échecs si il y a une solution de contournement. Ne pas surcharger le système conçu pour gérer l'échec avec ce qui équivaut à une capacité de configurer le système de plusieurs façons.