2017-08-28 1 views
2

Ive deux méthode qui jettent la même exception throws IOExceptiontype d'exception même avec le message d'erreur diffrent

le problème est que chaque méthode jeter de différentes raisons, j'Envelopper les méthodes dans la principale avec prise d'essai, quelle est la moyen recommandé pour le résoudre? J'ai besoin message différent pour chaque exception avec le même type ..

public static void main(String[] args) { 

try{ 

…. 


readFile(path); 

convert(file) 

} catch (IOException e) { 
    ….. 
} 


private static String readFile(String path) throws IOException { 
    //Here files requires IOException - Reason here cannot Read file 
    String lineSeparator = System.getProperty("line.separator"); 
    List<String> lines = Files.readAllLines(Paths.get(path)); 
} 


private static String convert(String file) throws IOException { 
    //Here reader requires also ioException- Reason here cannot parse file 
    ObjectMapper reader = new ObjectMapper(new YAMLFactory()); 
    Object obj = reader.readValue(file, Object.class); 

} 
+1

Créez votre propre exception puis –

+1

Appelez les deux méthodes dans des blocs try/catch séparés. –

+0

ou utilisez le même bloc et vérifiez le message d'erreur via equals ou contains pour vous assurer que l'exception a bien été levée. – Acewin

Répondre

4

Il y a plusieurs façons dont vous pouvez aborder ce sujet. Une façon, peut-être la plus lourde en termes de nouveau code que vous auriez besoin d'écrire, serait de lancer une exception personnalisée de chacune de vos méthodes d'aide. Ensuite, vous pourriez attraper chaque exception spécifique dans un bloc séparé.

Mais ce que je pourrais recommander ici est que vous simplement envelopper chacun des deux appels à vos méthodes d'assistance dans try-catch blocs séparés:

try { 
    readFile(path); 
} catch (IOException e) { 
    // handle first exception here 
} 

// more code 
try { 
    convert(file) 
} catch (IOException e) { 
    // handle second exception here 
} 

Ceci est assez propre et ne nécessite pas beaucoup de refactoring. Si vous continuez à rencontrer ce problème, envisagez éventuellement de créer des exceptions personnalisées pour votre application. Si vous regardez plusieurs bibliothèques Java, vous verrez qu'elles utilisent souvent leurs propres exceptions personnalisées.

Si vous souhaitez utiliser l'exception personnalisée, vous pouvez en définir une, par ex.

public class FileReadIOException extends Exception { 
    public FileReadIOException(String message) { 
     super(message); 
    } 
} 

puis l'utiliser:

private static String readFile(String path) throws FileReadIOException { 
    try { 
     String lineSeparator = System.getProperty("line.separator"); 
     List<String> lines = Files.readAllLines(Paths.get(path)); 
    } 
    catch (Exception e) { 
     throw new FileReadIOException(e.getMessage()); 
    } 
} 

try { 
    readFile(path); 
    // more code 
    convert(file) 
} catch (FileReadIOException e) { 
    // handle first exception here 
} catch (SomeOtherException e) { 
    // handle second exception here 
} 

Le code ci-dessus montrant exception personnalisée est un peu artificiel, parce que la réalité est que tout votre code est de lancer IOException. Créer des exceptions personnalisées dans votre cas n'ajoute pas beaucoup de valeur, car elles lancent déjà (légitimement) un IOException. Je ne suis pas sûr que cela n'a pas de sens de gérer un seul type d'exception. Plus généralement, si vous travailliez sur une grande application d'entreprise, vous utiliseriez des exceptions personnalisées pour gérer les situations qui ne fonctionnent pas dans votre propre code personnalisé.

+0

Pouvez-vous donner un exemple pour la première approche? –

+0

aussi le problème est que j'ai besoin d'abandonner le programme si une exception a été soulevée ... –

+0

Donc la deuxième approche est la recommandée? Je veux comprendre la meilleure pratique ... pas la solution courte –

1

Voici mes 5 cents

public static void main(String[] args) throws Exception { 

    String path = "path"; 
    String path2 = "path2"; 


    try{ 
     readFile(path); 
    } catch (IOException e) { 
     throw new Exception("read file exception", e); 
    } 

    try{ 
     convert(path2); 
    } catch (IOException e) { 
     throw new Exception("convert exception", e); 
    } 


} 


private static String readFile(String path) throws IOException { 
    //Here files requires IOException - Reason here cannot Read file 
    String lineSeparator = System.getProperty("line.separator"); 
    List<String> lines = Files.readAllLines(Paths.get(path)); 
} 


private static String convert(String file) throws IOException { 
    //Here reader requires also ioException- Reason here cannot parse file 
    ObjectMapper reader = new ObjectMapper(new YAMLFactory()); 
    Object obj = reader.readValue(file, Object.class); 
} 
1

Mon chemin est généralement de créer votre propre exception et le jeter comme ça

public class Snippet { 
    public static void main(String[] args) { 
     try { 
      String path = ""; 
      readFile(path); 
      String file = ""; 
      convert(file); 
     } catch (MyException e) { 
      // do whatever 
     } 
    } 

    private static String readFile(String path) throws MyException { 
     try { 
      String lineSeparator = System.getProperty("line.separator"); 
      List<String> lines = Files.readAllLines(Paths.get(path)); 
     } catch (Exception e) { 
      throw new MyException("Custom 'readFile' message", e); 
     } 
    } 

    private static String convert(String file) throws MyException { 
     try { 
      ObjectMapper reader = new ObjectMapper(new YAMLFactory()); 
      Object obj = reader.readValue(file, Object.class); 
     } catch (Exception e) { 
      throw new MyException("Custom 'convert' message", e); 
     } 
    } 
} 

class MyException extends Exception { 
    private static final long serialVersionUID = -3166824380774329449L; 

    public MyException(String message, Throwable cause) { 
     super(message, cause); 
     // TODO Auto-generated constructor stub 
    } 
} 

façon Tim est valable aussi.

1

@OP La meilleure personne pour résoudre ce problème serait vous-même. Il y a assez facilement plusieurs façons de résoudre cela. Vérifiez lequel vous convient le mieux.

Une des solutions selon moi est ci-dessous. Ceci est basé sur la raison pour laquelle IOException est superclasse à de nombreuses autres exceptions. IOException documentation

try { 
    readFile(path); 
} catch (FileNotFoundException e) { 
    // handle first exception here 
} catch (EOFException e) { 
    // handle 2nd exception here 
} 

Pour ce qui précède vous devez travailler pour savoir quel type de IOException est en cours de levée.

Une autre solution consiste à vérifier les messages d'exception individuels lorsque vous savez quels sont les messages attendus que vous pouvez recevoir.

try { 
    readFile(path); 
} catch (IOException e) { 
    if(e. getMessage().contains("TXT 1...") { 
      //Case handle #1 
    } else if(e. getMessage().contains("TXT 2...") { 
      //Case handle #2 
    } 
} 
1

La meilleure façon de gérer les exceptions est de ne pas les avoir. Lorsqu'une exception est levée, cela indique que le cycle de vie naturel de votre application a été interrompu pour une raison ou une autre. La plupart des exceptions sont explicites et vous fournissent une explication précise de ce qui se passe, donc créer de nouvelles exceptions et re-cartographier celles jetées est presque toujours contre-productif et peut entraîner plus de confusion que d'utilité (surtout si vous travaillez en équipe).

De plus, les exceptions n'ont pas besoin d'être terminales, dans la plupart des cas, un scénario peut être conçu pour réessayer/inviter différentes entrées, etc., pour s'assurer que le cycle de vie n'est pas interrompu. Tuer une application sur une exception peut créer plus de problèmes dans certains cas (par exemple: ne pas fermer correctement les fichiers, donc perdre les données traitées).

Maintenant à votre problème réel. Si vous avez deux composants ou plus, cela renvoie des exceptions non liées (le nom n'est pas une relation dans ce cas), il est préférable de ne pas les avoir dans la même structure try/catch car une solution de contournement sera nécessaire de tout ce qui peut encore sortir tout seul, ou n'a même pas besoin d'être initié.