Base et principes de base de la gestion des exceptions Java

Quand j'ai regardé le code source de Hadoop aujourd'hui, j'ai pensé au système sur lequel je travaillais récemment et j'ai découvert que de nombreuses méthodes de gestion des exceptions étaient erronées, et j'ai toujours suivi la méthode traditionnelle de gestion des exceptions. (c'est-à-dire utiliser les valeurs de retour pour identifier les anomalies des programmes qui se produisent). La déclaration de nombreuses méthodes dans Hadoop génère des exceptions, mais la déclaration de nombreuses méthodes dans mon système ne génère pas d'exceptions. Il détecte uniquement la situation anormale et génère un message d'erreur, mais ne lève pas d'exception.

La méthode readFields() de la classe Block sous le package org.apache.hadoop.hdfs.protocol :

public void readFields(DataInput in) throws IOException {    this.blockId = in.readLong();    this.numBytes = in.readLong();    this.generationStamp = in.readLong();    if (numBytes < 0) {      throw new IOException("Unexpected block size: " + numBytes);//抛出异常，要是的话就不会抛出，而只是System.out.println错误提示，
    }

1 S'il y a une exception levée dans le nom de la déclaration de la méthode. , puis dans le corps de la méthode, aucune exception ne peut être levée. Parce que vous pouvez inclure une description d’exception dans la déclaration de méthode, mais pas réellement la lancer ! L’avantage de procéder ainsi est que vous disposez d’abord d’une place pour l’exception et que vous pouvez lever cette exception plus tard sans modifier le code existant. Cette capacité est importante lors de la définition de classes de base abstraites et d'interfaces afin que les classes dérivées ou les classes implémentant des interfaces puissent lever ces exceptions pré-déclarées.

2. Pourquoi certaines déclarations de méthode n'ont-elles pas de levée, mais des exceptions sont levées dans le corps de la méthode ? Les exceptions héritées de RuntimeException peuvent être levées sans lancer de description d'exception ! Pour les exceptions d'exécution (également appelées exceptions non vérifiées), le compilateur ne nécessite pas de spécification d'exception. Les exceptions de type RuntimeException (et ses sous-classes) ne peuvent être ignorées que dans le code. La gestion des autres types d'exceptions est appliquée par le compilateur. La raison en est que RuntimeException représente une erreur de programmation.

3. Les exceptions d'exécution seront automatiquement levées par la machine virtuelle Java !

1. Bases de la gestion des exceptions
   1.1 System.out.println coûte cher. L’appel de System.out.println réduira le débit du système.

   1.2 N'utilisez pas la méthode inhabituelle printStackTrace() dans un environnement de production. printStackTrace imprimera la pile d'appels sur la console par défaut. Il est irréaliste d'accéder à la console dans un environnement de production.

2. Principes de base de la gestion des exceptions
   2.1 Si vous ne pouvez pas gérer une exception, ne l'interceptez pas.

   2.2 Si vous souhaitez le capturer, vous devez le capturer à proximité de la source de l'exception.

   2.3 N'avalez pas les exceptions que vous détectez.
   * (C'est une exception interceptée, mais ne fait rien)

   2.4 Sauf si vous souhaitez renvoyer l'exception, enregistrez-la.

   2.5 Lorsqu'une exception est réemballée puis renvoyée, n'imprimez pas de trace de statistique.

   2.6 Utilisez des classes d'exception personnalisées au lieu de lancer java.lang.Exception à chaque fois que vous devez lancer une exception. L'appelant de la méthode peut indiquer quelles exceptions doivent être gérées via des lancers – elle est donc auto-descriptive.

   2.7 Si vous écrivez une logique métier, le système doit lever des exceptions non vérifiées pour les erreurs qui ne peuvent pas être réparées par les utilisateurs finaux ; si vous écrivez un package tiers que d'autres développeurs peuvent utiliser, car les erreurs irréparables nécessitent une exception vérifiée. .

   2.8 Ne manquez jamais de déclarer les exceptions qui doivent être vérifiées, car l'écriture d'instructions throws rendra votre utilisation inconfortable.

   2.9 Des erreurs au niveau de l'application ou des exceptions système irréparables sont générées avec des exceptions non vérifiées.
   * (notez qu'il s'agit d'une erreur, ce qui signifie qu'elle ne peut pas être réparée, comme une erreur de fichier de configuration)

   2.10 Organisez vos méthodes selon la granularité des exceptions

Recommandations associées :

Connaissance de base de la gestion des exceptions et des erreurs Java

Reprendre les bases de Java (16) : Résumé de exceptions

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!