Discussion :

[valkeke]

Bonjour,

J'ai une petite question qui me chagrine, je suis en train de regarder hibernate et j'ai pris un code qui fonctionne, compile :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
public void create()
{
SessionFactory sessionFactory = new Configuration().configure().buildSessionFactory();
		Session session = sessionFactory.getCurrentSession();
		Transaction tx = session.beginTransaction();
		User user = new User("Dupont","Pierre");
 
		session.persist(user);
 
		System.out.println("User inséré avec clé=" + user.getId());
		tx.commit();
}

Quand je regarde la javadoc, la méthode commit : throws HibernateException.
Quand j'execute ce code, le compilateur ne me dit rien.... pour moi, lorsque je crée une méthode qui lève une exception, le client qui utilise cette fonction doit utiliser try catch ou mettre au niveau de la signature throws HibernateException pour continuer à propager l'exception.
Pourquoi dons mon code ci-dessus, pas besoin de tout ça???
j'espère être clair...

merci d'avance pour vos éclaircissements....

[tchize_]

C'est dans la base des règles sur les Exception, vous ne devez traiter que les exceptions qui n'étendent pas RuntimeException. Tout autre exception ou Throwable n'a pas de traitement forcé.

[valkeke]

Ok, mais j'avais pris pour habitude, sans trop me poser la question j'avoue, lorsque je crée des exception maison, métier..etc... de les faire hériter de la classe Exception.

J'essaie de me perfectionner dans le langage Java et donc j'ai du mal à voir les cas d'utilisations des exceptions RuntimeException dans une application car dans ce cas, aucun traitement ne pourra être fait lorsque une exception RuntimeException se lèvera....
Au niveau performance, je pense qu'il n'y a pas de différence entre les 2 types d'exceptions????

Pour moi, dès qu'il y a un problème exceptionnel(utilisation des exceptions), je dois avertir mon utilisateur final qu'une tache ne sait pas bien passer, donc j'ai du mal à voir l'utilité des RuntimeException...

Si quelqu'un a des exemples d'utilisations des RuntimeExceptions, quand les utilisées et pourquoi par rapport à la classe Exception???
merci par avance

[tchize_]

car dans ce cas, aucun traitement ne pourra être fait lorsque une exception RuntimeException se lèvera....

Et pourquoi? Tu peux la catcher si tu veux. Les RuntimeException s'utilisent quand on ne veux pas forcer l'appelant à faire soit un catch, soit un throws. Typiquement, les NullPointerException, les IllegalArgumentException etc sont des RuntimeException.

[adiGuba]

Salut,

Il s'agit d'une notion propre à Java : les checked-exceptions.
Par défaut les exceptions sont "checked", c'est à dire que le compilateur va vérifié qu'elles soient bien traitée ou déclarée dans la signature de méthode.

RuntimeException (et Error) correspond à des "unchecked-exceptions" qui ne sont pas vérifier par le compilateur (comme c'est le cas dans la plupart des autres langages).

Au niveau performance, je pense qu'il n'y a pas de différence entre les 2 types d'exceptions????

Il n'y a strictement aucune différence à l'exécution.
La seule différence vient du compilateur qui effectue des vérifications supplémentaire sur les "checked-exceptions".

Si quelqu'un a des exemples d'utilisations des RuntimeExceptions, quand les utilisées et pourquoi par rapport à la classe Exception???

C'est bien de traiter une exceptions lorsque tu peux proposer une alternative. C'est surtout vrai sur les saisies utilisateurs où tu peux demander de ressaisir.

Mais une grosse partie des exceptions ne peut pas être traité, et le programme devrait plutôt être arrêté. Dans ce cas là plutôt que de traiter toutes les exceptions il est préférable de les ignorer : cela remontera la pile d'appel et tuera le thread courant.

Tu te vois faire des try/catch partout pour traiter des NullPointerExcpetion, ArithmeticException, IllegalArgumentException, SecurityException, UnsupportedOperationException ou autres... ? Ce sont pourtant des exceptions qui peuvent survenir n'importe où !

C'est impossible et ce serait n'importe quoi !!!

Ces exceptions ne devrait pas arriver dans un cadre normal, et si elles arrivent tu ne pourrais pas vraiment proposer d'alternative. Donc la meilleure solution reste de les ignorer afin de stopper le traitement courant...

C'est un peu pareil pour HibernateException qui regroupe un peu toutes les exceptions que peut générer Hibernate (problème de cache, de mapping, erreur SQL, ...).

Tu comptes vraiment proposer une solution alternative à tous ces problèmes ???

La plupart du temps tu ne peux pas proposer d'alternative, donc le mieux reste de planter le programme.



A titre personnel je serais même plutôt contre les "checked-exceptions". J'estime qu'on devrait pourvoir ignorer n'importe quelles exceptions si on veut. Dans bien des cas il est préférable de planter le programme plutôt que de continuer sur une jambe avec un try/catch bidon comme c'est trop souvent le cas...




Bon il faut quand même présenter cela proprement. Planter le thread c'est bien mais par défaut cela affiche simplement un stacktrace. De plus en cas d'application multi-thread seul le tread courant est planté, ce qui selon le contexte n'est pas forcément souhaitable.

On peut utiliser Thread.setUncaughtExceptionHandler() ou Thread.setDefaultUncaughtExceptionHandler() pour intercepter ces erreurs et quitter proprement l’application...


a++

[tchize_]

A titre personnel je serais même plutôt contre les "checked-exceptions". J'estime qu'on devrait pourvoir ignorer n'importe quelles exceptions si on veut. Dans bien des cas il est préférable de planter le programme plutôt que de continuer sur une jambe avec un try/catch bidon comme c'est trop souvent le cas...

Tu te serait pas mis au Scala toi?

[adiGuba]

Tu te serait pas mis au Scala toi?

Et non

Au passage à ma connaissance Java est le seul langage à avoir des "checked-exceptions", donc tu aurais pu tenter un grand nombre d'autres langages

Par contre c'est vrai que j'englobe beaucoup de checked-exception dans une "unchecked-exception" afin de ne pas les traiter inutilement.

Et j'ai beaucoup hésiter à utiliser un hack du langage pour remonter silencieusement une checked-exception... mais ce n'est pas très propre



Perso je pense que la notion de "checked-exception" est une expérience louable, mais qui s'avère inadapté et trop contraignante dans de nombreux cas...


a++

[tchize_]

pour ça que scala l'a abandonné. J'ai laché scala car basé sur la jvm :p
Sinon, pour faire "plus propre" (*hum *hum*), lombok fournis l'annotation @SneakyThrows

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
import lombok.SneakyThrows;
 
 public class SneakyThrowsExample implements Runnable {
   @SneakyThrows(UnsupportedEncodingException.class)
   public String utf8ToString(byte[] bytes) {
     return new String(bytes, "UTF-8");
   }
 
   @SneakyThrows
   public void run() {
     throw new Throwable();
   }
 }

[valkeke]

Quand tu dis :

C'est un peu pareil pour HibernateException qui regroupe un peu toutes les exceptions que peut générer Hibernate (problème de cache, de mapping, erreur SQL, ...).

Tu comptes vraiment proposer une solution alternative à tous ces problèmes ???

La plupart du temps tu ne peux pas proposer d'alternative, donc le mieux reste de planter le programme.

Je ne veux pas proposer une solution alternative(pas de solution car il y a eu un problème exceptionnel !), par contre je ne trouve pas super de laisser l'application se plantait sans en avertir l'utilisateur avec un message..... un peu explicatif sur le plantage qui vient de se passer.....cela fait penser à une application avec des processus non maitrisés...
Ensuite comment tu fais pour logger l'erreur dans un fichier de log afin que le développeur comprenne un peu par la suite ce qui a pu se passer ??

Concernant par exemple, les NullPointerExcpetion si cela se produit dans ton application, c'est un problème qui ne devrait jamais arriver dans un développement professionnel, non ????

[tchize_]

si si, ca arrive souvent. Parce que le null était un conséquence d'un cas pas prévu de l'api X, dont la donnée est passée à l'api Y qui la transfère à un api Z qui elle apprécie pas. Et ça remonte tout du long.

On ne dit pas qu'il ne faut pas traiter les cas d'erreur à une niveau supérieur. Simplement, en général, certaines exceptions remontent pas mal dans la stack jusqu'à atteindre un niveau plus globale où elle pourra être gérée. Exemple:

l'utilisateur encode un formulaire (dossier d'un patient par exemple) et veut le sauver. Tu peux traiter à bas niveau le cas où il y erreur réseau, en rétablissant la connexion, mais tu pourra difficilement traiter en bas un exception SQL due à un conflit dans la DB. Pour cela, il faudra remonter jusque la couche UI qui dira, dans le pire des cas "ha bah, j'a iun problème, c'est pas sauver, réessayer?" Et si ça voulais dire à chaque niveau mettre the throws dans la déclaration, au niveau UI, on se gérerais une tartine monumentale d'exception et les déclaration des méthodes intermédiaires deviendraient kilométriques.

J'ai déjà travailler avec des API qui déclaraient tout, on avait parfois 25 catch() l'un derrière lautre pour tout traiter

[adiGuba]

par contre je ne trouve pas super de laisser l'application se plantait sans en avertir l'utilisateur avec un message..... un peu explicatif sur le plantage qui vient de se passer.....cela fait penser à une application avec des processus non maitrisés...
Ensuite comment tu fais pour logger l'erreur dans un fichier de log afin que le développeur comprenne un peu par la suite ce qui a pu se passer ??

Ben justement via un UncaughtExceptionHandler ou un mécanisme similaire.

Perso je fais des applications web et les exceptions génèrent une page 500 avec remontée par email du stacktrace + infos utiles...


Après ca dépend de ton besoin et de ce que tu veux :

• Dans une application serveur il faut arrêter le traitement courant uniquement (le thread).
• Dans une application cliente ca peut varier. Selon les cas on peut se contenter de tuer le thread mais souvent il est préférable de quitter l'application. Voir de le proposer à l'utilisateur...

Mais comme je l'ai dit cela peut se faire facilement via les UncaughtExceptionHandler. Par exemple en générant une boite de dialogue :

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
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
import java.awt.Dimension;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.io.PrintWriter;
import java.io.StringWriter;
 
import javax.swing.JCheckBox;
import javax.swing.JOptionPane;
import javax.swing.JScrollPane;
import javax.swing.JTextArea;
import javax.swing.SwingUtilities;
 
public class Main {
 
 
	public static void main(String[] args) throws Exception {
 
		// On défini le traitement par défaut des exceptions non-traitées 
		// pour tous les threads (on peut redéfinir cela indépendamment pour chaque thread)
		Thread.setDefaultUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler() {
			@Override
			public void uncaughtException(Thread t, Throwable e) {
 
				StringWriter writer = new StringWriter();
				e.printStackTrace(new PrintWriter(writer));
 
				final JScrollPane stacktrace = new JScrollPane(new JTextArea(writer.toString()));
				stacktrace.setPreferredSize(new Dimension(200, 80));
				stacktrace.setVisible(false);
 
				final JCheckBox showStacktrace = new JCheckBox("Afficher le stacktrace");
				showStacktrace.addActionListener(new ActionListener() {
					@Override
					public void actionPerformed(ActionEvent e) {
						stacktrace.setVisible(showStacktrace.isSelected());
						SwingUtilities.windowForComponent(stacktrace).pack();
					}
				});
 
				Object[] message = {
						"Une erreur est survenue. Le programme va s'arrêter !",
						"Veuillez contacter le service informatique.",
						" ",
						showStacktrace,
						stacktrace
				};
				JOptionPane.showOptionDialog(null, message,
						"Erreur dans le programme",
						JOptionPane.DEFAULT_OPTION, JOptionPane.ERROR_MESSAGE,
						null, null, null);
				System.exit(1);
			}
		});
 
		// ca plante !
		throw new RuntimeException("badaboum !!!");
	}
}

Concernant par exemple, les NullPointerExcpetion si cela se produit dans ton application, c'est un problème qui ne devrait jamais arriver dans un développement professionnel, non ????

Ca ne devrait pas arriver... Comme les bugs ne devraient pas arriver, comme les erreurs SQL ne devrait pas arriver, comme les mauvaises saisies ne devraient pas arriver...

Au contraire c'est justement parce que cela ne devrait pas arriver qu'il est encore plus important de gérer cela proprement !



a++