Discussion :

[olivier252]

Bonjour,

Je me remets doucement à java et impossible de faire fonctionner une "bête " insertion en BDD...
Je précise que mes données sont récupérées de 2 JTextField d'une fenêtre swing (nom et prénom pour le test).
Voici ma méthode :

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
20
21
22
23
24
 
public void addPersonn(Personne p) {
		PreparedStatement pstmt;
		String request = PersonneQuery.QUERY_INSERT_PERSONNE;
 
		try {
			pstmt = connection.prepareStatement(request);
			pstmt.setString(1, p.getNom());
			pstmt.setString(2, p.getPrenom());
 
			int flag = pstmt.executeUpdate();
			if (flag >= 1) {
				System.out.println(flag + "ligne(s) ajoutée(s)");
				connection.commit();
			} else {
				System.out.println("pas d'insertion");
			}
			pstmt.close();
 
		} catch (SQLException e) {
			e.printStackTrace();
			ConnexJDBC.rollback();
		} 
	}

voici la pile d'erreur :
"Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException;
at com.cesi.dao.PersonneDao.addPersonn(PersonneDao.java:17); la ligne 17 correspond à la ligne 7 ici; Je ne comprends pas comment ma référence pstmt est nulle.

Merci

[joel.drigo]

Salut,

la ligne 17 correspond à la ligne 7 ici; Je ne comprends pas comment ma référence pstmt est nulle.

Ce n'est pas pstmt qui est null, mais connection !
Une NullPointerException ne concerne jamais ce qui est affecté, mais l'expression évaluée pour déterminer la valeur à affecter.

[olivier252]

En effet, j'aurais du dire "pstmt pointe vers null" ?

[joel.drigo]

En effet, j'aurais du dire "pstmt pointe vers null" ?

Non plus. pstmt n'existe plus, parce que c'est connection.prepareStatement(request) qui provoque la NullPointerException, et que ceci provoque l'arrêt immédiat de l'exécution, sortie de la méthode addPersonn, et donc pstmt n'existe plus, donc ne pointe sur rien du tout.
C'est connection qui est null. C'est la seule possibilité avec une NPE sur cette ligne. Il faut donc chercher pourquoi. A priori, aucun code exécuté ne lui affecte une valeur.

Au passage, je viens de le voir, pourquoi fait-on un rollback sur ConnexJDBC, alors qu'on exécute la requête et on la commit par connection ?

A noter également que le statement n'est pas fermé en cas d'exception SQL (dans le cas où le statement est bien créé évidemment). Utilise un try-with-resource.

[olivier252]

Ok,

Au passage, je viens de le voir, pourquoi fait-on un rollback sur ConnexJDBC, alors qu'on exécute la requête et on la commit par connection ?

En fait, c'est en cas d'erreur dans le try que le rollback se produit, mais le sns de ta remarque m'échappe sans doute
Voici la méthode rollback de ConnexJDBC

Code :

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

1
2
3
4
5
6
7
8
9
 
public static void rollback() {
		try {
			cnx.rollback();
		} catch (SQLException e) {
			System.out.println(e.getMessage());
		}
		System.out.println("rollback effectué");
	}

A priori, aucun code exécuté ne lui affecte une valeur.

L'appel de la constante QUERY_INSERT_PERSONNE fait référence à l'interface PersonneQuery suivante :

Code :

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

1
2
3
4
 
public interface PersonneQuery {
	static String QUERY_INSERT_PERSONNE = "insert into personne_table (nom, prenom) values(?,?)";
}

Utilise un try-with-resource.

Comme ceci ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
public void addPersonn(Personne p) {
		String request = PersonneQuery.QUERY_INSERT_PERSONNE;
 
		try (PreparedStatement pstmt = connection.prepareStatement(request)){
 
			pstmt.setString(1, p.getNom());
			pstmt.setString(2, p.getPrenom());
 
			int flag = pstmt.executeUpdate();
			if (flag >= 1) {
				System.out.println(flag + "ligne(s) ajoutée(s)");
				connection.commit();
			} else { ...............................

Du coup le try-with-ressources permet de se passer de fermer le PreparedStatement (

Code :

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

pstmt.close()

grace à l'interface Autoclosable (si j'ai compris ?)

MErci

[joel.drigo]

En fait, c'est en cas d'erreur dans le try que le rollback se produit, mais le sns de ta remarque m'échappe sans doute
Voici la méthode rollback de ConnexJDBC

Code :

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

1
2
3
4
5
6
7
8
9
 
public static void rollback() {
		try {
			cnx.rollback();
		} catch (SQLException e) {
			System.out.println(e.getMessage());
		}
		System.out.println("rollback effectué");
	}

Le sens de ma remarque est que

1. normalement, on fait une transaction à partir d'une même connexion : tous les ordres doivent être lancés avec la même instance de java.sql.Connection. Sinon on fait des insert dans une transaction et qu'on en rollback une autre en cas d'erreur, ça ne sert à rien.
2. si ConnexJDBC est une connexion active (ou plutôt cnx exactement dans ton cas) et que tu utilises connection pour faire l'insert, peut-être que connection n'est pas initialisée, même si cnx l'est. Rien ne me permet de savoir si cnx et connection pointent vers la même instance de Connection, ou si même, l'une ou l'autre pointe bien vers une instance de Connection (donc est null ou pas). Le sens de ma remarque était que cette distinction de variables pouvaient être un indice pour comprendre pourquoi connection est null. C'est courant lorsqu'on multiplie les variables, surtout pour représenter la même chose : on affecte une variable et on oublie de le faire pour l'autre. Pire, on affecte une valeur différente aux deux, ou c'est ce qui finit par se passer au cours de l'exécution, alors qu'elles sont censées représenter la même chose.
3. et pourquoi faire une méthode static dans une autre pour faire le rollback sur une autre variable, et pas faire directement connection.rollback() dans la méthode de traitement, au moins par cohérence.
4. en résumé, tout ça pour continuer à dire qu'il faut s'intéresser à cette variable connection pour savoir pourquoi elle vaut null lors de l'invocation de preparedStatement().

L'appel de la constante QUERY_INSERT_PERSONNE fait référence à l'interface PersonneQuery suivante :

Code :

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

1
2
3
4
 
public interface PersonneQuery {
	static String QUERY_INSERT_PERSONNE = "insert into personne_table (nom, prenom) values(?,?)";
}

Ok, mais ce n'est pas pertinent dans la problématique du NullPointerException qui nous occupe.
Cependant, faire des interfaces pour uniquement définir des constantes a été en usage certes, y'a une vingtaine d'années (et je l'ai utilisée moi-même), mais ça fait longtemps qu'on sait qu'il ne faut pas procéder comme ça. Une interface n'est pas faite pour ça. Si il est tentant de faire une interface en se disant qu'on peut implémenter de l'interface pour hériter des "constantes", il est préférable de faire une classe normale (éventuellement avec constructeur private pour éviter une instanciation contre productive), et de faire des imports static éventuellement. Avec une classe standard, on fait référence à la constante avec la même facilité que si c'était une interface, donc on ne gagne rien à faire une interface. Eventuellement, si la "constante" a besoin d'être qualifiée, un enum est envisageable, ce qui facilite par ailleurs le traitement masse.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
public void addPersonn(Personne p) {
		String request = PersonneQuery.QUERY_INSERT_PERSONNE;
 
		try (PreparedStatement pstmt = connection.prepareStatement(request)){
 
			pstmt.setString(1, p.getNom());
			pstmt.setString(2, p.getPrenom());
 
			int flag = pstmt.executeUpdate();
			if (flag >= 1) {
				System.out.println(flag + "ligne(s) ajoutée(s)");
				connection.commit();
			} else { ...............................

Du coup le try-with-ressources permet de se passer de fermer le PreparedStatement (

Code :

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

pstmt.close()

grace à l'interface Autoclosable (si j'ai compris ?)

En réalité, le try-with-resources ferme de lui-même l'ensemble des ressources crées, ici le PreparedStatement en effet (grâce à l'interface AutoCloseable oui). C'est le développeur du coup qui peut se passer d'invoquer explicitement la méthode close().