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++