Classes anonymes et exceptions

Version imprimable

Bonjour,

J'utilise une classe anonyme (pour implémenter l'interface ThreadLocal) et l'une des fonctions définie peut renvoyer une exception.
Je voudrais pouvoir faire remonter cette exception dans la classe du dessus (MaClasse) d'une manière ou d'un autre mais je ne trouve pas comment faire.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 public MaClasse { private static ThreadLocal<BaseDeDonnees> bd = new ThreadLocal() { @Override protected synchronized Object initialValue() { return new BaseDeDonnees(...); // Lève une Exception } }; public static BaseDeDonnees getBd() { return bd.get(); // Provoque l'appelle à initialValue() } }
Je n'ai pas le droit de déclarer un "throws Exception" sur la méthode initialValue() car elle est surchargée donc je ne peux pas changer son prototype.

J'espère que c'est possible. Merci.

Dans ce cas, une idée est d'encapsuler ton exception dans une erreur. Ainsi, tu n'auras plus de problème avec la méthode initialValue.

Tu pourras ensuite retrouver ton exception d'origine.

En gros, tu obtiens (code non testé):

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
public MaClasse {
	private static ThreadLocal<BaseDeDonnees> bd = new ThreadLocal() {
		@Override
		protected synchronized Object initialValue() {
                    try{
			return new BaseDeDonnees(...); // Lève une Exception
                    }
                    catch(Exception e){throw new MyError(e);}
		}
	};
 
	public static BaseDeDonnees getBd() {
            try {
		return bd.get(); // Provoque l'appelle à initialValue()
            }
            catch(MyError e) {
              Exception ex =  e.getCause();
               ...
            }
	}
}

08/08/2009, 12h29
Alain Defrance

Bonjour,

Même si c'est possible, il est "déconseillé" de soulever des erreurs. En effet les erreurs ne sont pas des exceptions et sémantiquement une erreur DOIT arreter le programme. Ce sont des évenements très grave dans la vie d'un programme, aussi il est déconseille de les utiliser pour ce type d'utilisation.
En revanche il est possible d'utiliser des RuntimeException, qui sont unchecked (c'est-à-dire qu'il n'est pas imposé de les catcher ni de préciser un throws en cas de non traitement de l'exception dans une methode). Le comportement reste le même qu'avec les errors mis à part que c'est plus approprié. On pourra la catcher dans le code appelant pour traiter l'exception.
10/08/2009, 10h12
Luke58

Avec les Error et RuntimeException (je vais garder ça vu que c'est plus approprié), ça marche comme je voudrais, merci !