[Exceptions] récupérer erreur oracle

Hello,

Je sais; je pose beaucoup de questions mais faut pas oublier que je debute et que je dois etre opérationnelle tt de suite.
Bref, voilà ma question. Je souhaite recuperer les messages d'erreur générés par oracle afin de les afficher dans une boite de dialogue. J'ai vu que le traitement des erreurs etait effectué la classe ActionErrors mais il faut aussi un fichier de ressources. Comment faire sans fichier?

Merci d'avance :D

[ Modéré par Viena ]
Ajout d'un tag dans le titre : plus un titre est précis, plus les réponses le sont.
:arrow: Les Règles du Forum

Les ActionErrors est la solution de gestion des erreurs proposée par Struts.

Dans un premier temps, tu vas devoir te pencher sur les Exceptions Java, pour gerer l'erreur dans le code Java, afin de pouvoir passer ses erreurs aux couches supérieures, puis finalement à l'utilisateur, en utilisant par exemple les ActionErrors.

En ce qui concerne le traitement des Exceptions en Java, tu peux regarder:
http://www.churchillobjects.com/c/11012.html (en anglais)

Dans ton cas, l'exception qui t'interesse (erreur Oracle) est SQLException

OK! Je pense que je peux récuperer l'erreur dans le bloc catch de mon action mais je ne sais pas comment le remonter à l'ActionErrors vu que celui-ci fonctionne avec un fichier de ressource. C'est là mon soucis!!!
Tu as une idée?

Bcp d'idées :)

Typiquement, entoure ton bloc à problèmes d'un:

Code:

---

1 2 3 4 5 6 7 8 9 10

try { ... } catch (SQLException ex) { logger.error("Une erreur SQL s'est produite") //Logge l'erreur dans ton API de logging ActionErrors myErrors = new ActionErrors(); myErrors.add(ActionMessages. GLOBAL_MESSAGE,new ActionMessage("ta.cle")); this.addErrors(request,myErrors) }

---

Ca doit marcher avec cette syntaxe en struts 1.2 (désolé, je suis encore en 1.1...)

ben moi c'est pire!!! J'utilise wsad et dessus c'est struts 1.0 qui est installé :(
Est ce que ça va marcher?

Normalement oui, mais essaies, tu seras fixé :wink:
On ne sait jamais, ça depend de la façon dont ils sont couplés.

OK! Je file essayerc tout ça et je vous dis si ça marche :D

Quelle idée de travailler en struts 1.0? 8O

Enfin, de toute façon, je peux déjà réécrire en struts 1.1, ca doit être plus proche de ce que tu dois faire:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

ActionErrors myErrors = new ActionErrors(); try { ... } catch (SQLException ex) { logger.error("Une erreur SQL s'est produite") //Logge l'erreur dans ton API de logging myErrors.add(ActionErrors.GLOBAL_ERROR,new ActionError("ta.cle")); } if (!myErrors.size()>0) { saveErrors(request, myErrors); } return ... ;

---

A priori, comme ça, c'est déjà plus compatible Struts 1.0

Juste une remarque de conception.
Je ne pense pas que dans le même code on doivent traiter les SQLException et les ActionError.
Les SQLException doivent être interceptées dans les couches basses, c'est à dire dans la couche d'accès aux données ou au pire dans la couche du dessus ("métier", "application"). Dans cette couche, les SQLException doivent être éventuellement relevées sous une identité différentes, je veux dire avec une sémantique dédiée à la couche (pas la couche SQL justement).
Les ActionError doivent, elles, être la conséquence d'une levée d'exception "métier", celle précédemment décrite. Si vous voulez que la couche C du MVC intercepte des exceptions des couches basses, ces couches basses doivent lever des RuntimeException et la couche C ne doit les intercepter qu'en tant que RuntimeException et ne doit pas se soucier de leur nature réelle.

Bref, lisez ce qu'en pense Rod Jonhson l'inventeur de SPRING, je pense que sa position est excellente sur le traitement des exceptions.

8O J'ai rien compris ego!
Et où puis-je trouver des infos sur ce Rod Jonhson?
Et pour toi denis, je n'ai pas choisi de travailler en struts 1.0 mais j'ai dû partir d'une configuration existante!

ce que je veux dire c'est que ce n'est pas dans les Actions Struts qu'il faut exécuter du code SQL.
Tu dois avoir au moins une séquence d'appel du genre :

1 2 3
Action --> Objet métier --> Objet accès données (ici il y a le SQL)

C'est au niveau 3 que tu as le SQL et le catch de SQLException. Dans ce catch tu dois renvoyer une autre exception du genre "Impossible de créer l'objet X", cette exception peut alors remonter dans 2 qui peut ou non l'intercepter et renvoyer une autre exception du genre "Transaction virement impossible". L'Action récupère donc les exceptions envoyées par 2.

Pour Rod Jonshon : www.springframework.org (tu y trouveras des références à ses bouquins)

Sur le principe, je suis d'accord avec ego.

Mais, bon, après le principe, il est tellement plus simple de faire du SQL dans une couche de persistence (appellée 3 précedemment) qui en cas d'erreur SQLException la catch, la loggue, et la renvoie sous le même nom, plutot que d'inventer une nouvelle erreur.
De meme la couche 2 elle aussi catche l'exception, la loggue et la renvoie.

Finalement, l'Exception arrive dans l'Action struts, mais pas complétement comme un cheveux sur la soupe.

Ceci dit, l'argument de Ego est totalement justifié. On pourrait penser à une erreur de type InstanciationException passée de la couche 3 à 2 puis ServiceException passée de 2 à 1. En effet, la couche 1 n'a aucun besoin de connaitre la nature réelle de l'erreur qui s'est produite en couche 3.

Enfin, sur le principe, mes explications restent valable. J'avais choisi la solution la plus simple à expliquer, plutôt que la plus rigoureuse :P

Le top est d'utiliser la méthode que te propose DenisC en prenant en compte les conseils de conception de Ego...
en effet c'est tres important de gérer les exceptions et de les remonter de façon à ce que la couche service ou ihm (la derniere couche koi...) ne gère qu'une exception finale (technique ou fonctionnelle...mais on se fiche que ce soit une SQLException ou une ClassCastException...au final y'a une erreur) pour l'ajouter au final dans le ActionError
En résumé faut aller du particulier....au général...
le particulier ce serait le SQLException
le général ce serait le ActionError ou dedans tu ne rajouterais que des Exception en général (technique ou fonctionnelle...)

= )

Tout à fait d'accord avec ce scénario.
C'est ce que j'ai voulu dire en fin de première réponse sur les RuntimeException. Si la SQLException doit remonter jusque dans l'Action, l'action ne doit pas l'intercepter en tant que SQLException mais en tant qu'Exception. Si on ne fait pas cela, il y a trop de couplage entre les couches hautes et les couches basses.
Quand on traite des exceptions, il faut savoir si on veut traiter des "Checked-Exceptions" ou des "Unchecked-Exceptions" et ensuite, on encapsule ou non les exceptions des couches basses en fonction de la stratégie de traitement

OK. J'ai bien compris ce que vous m'avez dit. De toutes les façons, je comptais faire un mix de ce que denisC et ego m'ont dit. Je vais voir ce que ça donne.En tous cas, merci bcp bcp bcp de votre aide :wink:

Juste pour clarifier un peu le débat qui est, ma foi, passionnant (les exceptions en java!!!), quelques définitions sur les checked et unchecked exceptions.

Les checked exceptions héritent de java.lang.Exception. Ce sont les exceptions mises en avant par Sun à travers java depuis le début du langage. Quand on lance (throw) une checked exception, le compilateur nous oblige à la déclarer au niveau de la signature de la méthode (throws CheckedException) ce qui est bien quand on veut obliger l'appelant à gérer cette exception, mais qui est lourd sinon. Quand on appelle une méthode qui lance une checked exception, le compilateur nous force à la catcher explicitement (try/catch) ou à la relancer.

Les unchecked exceptions héritent de java.lang.RuntimeException. Le compilateur ne force pas une méthode qui lance une unchecked exception à la déclarer dans sa signature (throws) et ne force pas, non plus, une méthode appelante à la catcher explicitement.

Dans une architecture avec trois tiers logiques (présentation, métier, accès aux données), si on n'encapsule pas les exceptions sql (qui sont toutes checked) dans une unchecked exception, on doit donc déclarer explicitement java.sql.SQLException sur chaque méthode métier qui appelle un DAO, puis catcher dans le contrôleur. Ce qui a pour effet pervers de lier la couche métier à l'API JDBC! Hérésie! De plus, la plupart des exceptions SQL qui ne sont pas traitées directement au niveau d'un DAO sont en général irréparables (connexion à la base interrompue par exemple) elles doivent donc être gérées de manière globale et donc il est inutile d'alourdir chaque contrôleur avec des catchs.

Spring propose une couche d'abstraction sur JDBC qui permet d'encapsuler chaque exception JDBC dans une exception unchecked et donc d'éviter de faire ce travail à la main. Une raison de plus pour utiliser Spring, et ce n'est pas ego qui me contredira, n'est-ce pas? :wink:

J'ai un blog

A ça c'est sûr !

J'essayes d'expliquer les choses, parfois mais cela me démange de répondre toujours par : "Mais utilisez SPRING et vous n'aurez pratiquement plus de questions à vous poser..."

Lisez le bouquin de Rod Jonhson sur le design des applications J2EE !!!

Citation:

---

Envoyé par ceddup

Les checked exceptions héritent de java.lang.Exception.

---

Soyons tatillons jusqu'au bout, les Unchecked Exceptions dérivent de RunTimeExceptions. Les Checked Exceptions sont tous les dérivés de Exception, sauf RunTimeException et ses dérivées.

En effet RunTimeExceptions est une sur classe de Exception :)

A part ca, je vais jeter un coup d'oeil à Spring, ca a l'air intéressant...

J'aurais plutôt dit :

Citation:

---

En effet RuntimeException est une sous classe de Exception

---

:langue:

Mais on va dire que j'ergote :wink:

Pour Spring, ça vaut le coup d'acheter un livre parceque la documentation, comme souvent sur les projets open-source, c'est plutôt pour ceux qui ont déjà compris les principes généraux.

Comme on est un peu speed (livraison demain), on a fait une gestion d'erreurs simples avec les infos que vous m'avez donné. Par contre, Spring m'intéresse donc je désire acheter un bouquin dessus. Je remercie donc ego pour l'url qu'il m'a fourni. Merci à vous tous!!!!!!!!!
youpiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii :bravo:

conseil peut être inutile vue l'urgence mais....se pencher sur la gestion des erreurs 2 jours avant la livraison c'est la garantie d'emmer...

Une bonne gestion d'erreurs ça se pense au début du projet de telle sorte que tout le monde dans l'équipe puisse suivre les mêmes règles et puis parce que cela peut être hyper structurant pour ta conception

Mais en utilisant SPRING est ses bons principes, tous cela ira de soi

Merci pour le conseil ego. C'est un peu ce que j'ai dit à l'equipe il y a quelques jours quand ils m'ont poussé à bout. D'autant plus que j'ai pris le projet en cours donc je ne pouvais pas tout refaire :(