Discussion :

[stof]

Bonjour,

J'ai une classe GenericJpaDAO a:

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
16
17
18
19
public class GenericJpaDAO implements IGenericDAO {
 
	protected static Log log = LogFactory.getLog(GenericJpaDAO.class);
 
	@PersistenceContext(unitName = "myappli.hibernate")
	EntityManager em;
 
	public Object getReference(Class _class, Object _object) {
		return em.getReference(_class, _object);
	}
 
	public void createObject(Object object) {
		try {
			em.persist(object);
		} catch (LazyInitializationException lie) {
			em.merge(em.merge(object));
		}
	}
}

Si dans mon appli, je fais :

Code :

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

1
2
3
4
5
try {     
  createObject(myObj);
} catch (Exception e) {
   log.error("je passe jamais ici!!");
}

Je ne tombe jamais dans le catch.

Par exemple, j'essaie de créer un objet dans une table avec la même clé primaire qu'une ligne déjà en base
-->j'ai dans mes logs java.sql.BatchUpdateException: ORA-00001: unique constraint (PREVL.PK_MYTAB) violated
bla, bla, bla
Alors que j'avais bien prévu le cas pour ne rien faire en cas d'échec de création de la ligne.

Merci.

[Kazh Du]

ta méthode createObject ne remonte pas d'exception, ne t'attend donc pas à ce qu'elle puisse en sortir. Pour cela il faudrait rajouter "throw Exception" à la déclaration de ta méthode.
Par contre si tu n'as pas d'erreur lors de l’exécution (ton IDE ne "râle" pas parce qu'il s'attend à une gestion d'erreur), c'est que celle-ci est traitée ailleurs.
Il ne te reste plus qu'à aller en profondeur dans ton code... Bon courage !

[stof]

(..)c'est que celle-ci est traitée ailleurs.
Il ne te reste plus qu'à aller en profondeur dans ton code...

C'est tout le problème : aucune idée de ce qu'est le "ailleurs" parce qu'a priori, je ne peux creuser plus bas que em.persist(object);

[OButterlin]

Le problème n'est pas là, c'est sur l'opération de commit que tu as ton exception, tu est déjà sorti de ta méthode create...
En clair, si tu avais une valeur incorrecte dans ton objet (type par exemple), tu aurais une exception dans createObject()
Là, c'est une contrainte d'intégrité qui claque => sur commit uniquement

[stof]

OK, donc je ne peux rien intercepter dans mes méthodes Java pour éviter de voir cette erreur qui ne m'intéresse pas? (j'ai déjà un try...catch qui est sensé me permettre de gérer le cas où l'objet n'a pas été créé)

[OButterlin]

Si, tu peux, mais pas au même endroit...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
Code appelant
...
try
{
   monEJB.createObject();
}
catch (...)
{
   ...
}

Du coup, tu peux peut-être encapsuler le tout dans une méthode pour éviter d'avoir à trainer le tout. En passant par une façade, tu masques le problème.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
Façade
...
public void createObject(MonOjbet obj)
{
   try
   {
      monEJBMetier.createObject(obj);
   }
   catch (Exception e)
   {
       ...
   }
}

Une alternative consiste à utiliser un contexte extended qui te permet de gérer les transactions manuellement. Ton problème de base est lié au fonctionnement "normal" de JTA (c'est le conteneur qui gère les transactions), on peut lui dire de faire autrement.