Discussion :

[touh]

comment savoir que dans une methode il ya des exception

[efficks]

Tu fouilles pour ta méthode dans les spécifications de l'API Java.
Voici l'adresse pour les spécification selon ta version de java :
http://java.sun.com/reference/api/index.html

Tu n'as qu'à choisir ta version.

[e1lauren]

dans l'api quand il y a :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
methode () throws *Exception

voila pas plus compliqué ... et la tu doit faire un try.. catch pour recuperer l'exception

[blech ducou]

Si tu veux savoir en cours d'execution si une methode possède des exceptions (méthode déclarée comme : methode () throws *Exception)il te faut aller voir du coté de la classe java.lang.reflect.Method

il y a une methode getExceptionTypes() qui renvoie un tableau vide de classes si ta methode ne possède pas d'exception.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
Object o;//ton objet
Class c = o.getClass(); //la classe de ton objet
Method mArray[] = c.getDeclaredMethods();//toutes les methodes de ta classe
for(int i=0;i<mArray.length;i++) {
    Method m = mArray[i];
    Class eClass [] = m.getExceptionTypes();
    if(eClass.length != 0) {
        System.out.println("La methode "+m.getName()+" possède les exceptions suivantes :");
        for(int j=0;j<eClass.length;j++)  {
            Class exceptClass = eClass[j];
            System.out.println(exceptClass.getName());
        }
    }
}

C.

[efficks]

Le meilleur moyen est d'aller voir comme je disais les spécifications de l'API Java.

[ghorgor]

Et puis tu as la methode bourrin, quand ca plante à la compilation !

[_Mac_]

Et puis tu as la methode bourrin, quand ca plante à la compilation !

Ah !! J'allais le dire !! Ca a le mérite d'être directe et simple, comme méthode.

[efficks]

Quelle belle méthode vous démontrez ici. C'est avec ces méthodes là que la programmation et l'informatique perds de sa crédibilité!
C'est vraiment pas fort comme suggestion.

Si une erreur survient dans le programme, c'est le client qui va être content d'abord![/quote]

[berg]

si tu utilise eclipse eclipse te previent que cette methode peut soulever des exception et te les proposent ^^. Sinon c'est dans l' API.

[bouye]

Quelle belle méthode vous démontrez ici

C'est parfois le seul moyen de catcher des cas particulier dans lesquels des RuntimeException sont lancees. En effet toutes ces exceptions et autres erreurs (NullPointerException, IllegalArgumentException, ...) n'ont pas besoin d'etre declaree dans la clause throw d'une methode. Et donc elles ne sont parfois pas documentees/declarees soit parce que le programmeur est un gros faineant soit tout simplement parce que c'est difficile a faire a cause de la tracabilite nottement quand on utilise une large API (ou l'appel d'une fonction peut en fait declencher des appels recursifs a 10~20 sous-classes...).

Extrait de la doc de RuntimeException :

A method is not required to declare in its throws clause any subclasses of RuntimeException that might be thrown during the execution of the method but not caught.

C'est pire encore pour des trucs genre OutOfMemoryError qui sont difficiles a attraper pour le moment (Java 5.0).

Si une erreur survient dans le programme, c'est le client qui va être content d'abord!

C'est bien pour ca qu'on fait des tests, des tests et encore des tests avant de livrer un programme
... et qu'on fournis des mises-a-jour et des patches apres la livraison...