Salut, je voudrais savoir si vous savez comment rattraper une erreur qui vient d'un driver jdbc...
 

 
C'est pas une exception, et je ne sais pas comment récupérer un truc comme ça.
je n'ai jamais vu ça avant, et je n'ai rien trouvé en faisant une recherche...
merci d'avance

Rhoooo, il y a un goret qui a mis un exit après avoir fait un stacktrace

j'ai rien compris ...

Je pense que monsieur confond la chaîne de cause des exceptions et les noms des méthodes dans la tacktrace. Ou alors il a désigné l'étage ou il veut arrêter (catch) la remontée ou débugger.
 
Oué en fait j'en sais pas plus que toi ...

- y'a pas de exit
- je ne confonds rien
 
ce truc apparait dans aucun stacktrace... il ne rentre dans aucun cas de catch, c'est un message d'erreur que je reçois lorsque je fais appel au driver jdbc et qu'il ne peut pas ouvrir de connexion.
 
si c'était une simple exception, je pense que je saurais comment la récupérer
 
donc comme c'est pas une exception, je ne sais pas comment récupérer cette erreur... et j'aimerais bien pouvoir le faire quand même
 
si c'est le premier code qui vous gêne, ne vous en occupez pas, il est juste là pour servir de témoin  
d'ailleurs je vais l'enlever, hop.

Le pb vient pas du fait que le coder du driver jdbc à fait un e.printStackTrace(System.err) puis n'a pas relancé l'exception en l'enveloppant éventuellement dans une SQLException ?

C'est quelle version du driver jdbc, histoire d'aller  lire les sources ?

http://java.sun.com/j2se/1.4.2/doc [...] rning.html
 
maintenant, c'est bizarre qu'il foute un warning et loggent un FATAL, mais bon

le bon lien serait plutot ca nan ?  http://java.sun.com/j2se/1.4.2/doc [...] Warnings()
Mais c'est assez surprenant qu'ils stacktaracent () une exception au sein du driver jdbc ....

bah euh sur la doc de SQLWarning il est écrit ce que c'est et comment les retrouver, et y'a un @see Connection.getWarnings donc bon

ouais, mais en lisant rapidement une première fois j'ai loupé l'info et j'ai cru que tu avais mal compris la question ... je précisais juste un peu les choses ...
 
Qu'est ce que t'en penses du stacktrace en dur dans le driver ? ca te parait pas louche à toi ?

si

J'en vois tous les jours perso ...

ha boooon c'est comme ça qu'on imprime une stacktrace!? on savait pas tien!
 
j'en vois souvent aussi, mais bcp plus rarement dans du code de production

la version du jdbc est un jdbc pour postgres : pg73jdbc3.jar
version 3 pour postgresql 7.3
 
pour la portion de code suivante :
 

 
j'ai le retour suivant :
 

 
c'est donc bien ce que je récupère comme exception, n'en déplaise à mes tracteurs
et j'ai toujours pas trouvé de solution, mis à part un test sur le message, genre
 

ben alors tu l'as ton exception
c'est quoi le probleme ?

haaa putain !
tout le monde avait compris que ct le driver qui avait imprimé l'exception !?!
 
je vois pas bien pourquoi tu voudrais plus recuperer cette exception là qu'une autre. tu peux pas te connecter, tu peux pas te connecter quoi

c'est bien à ce niveau là que j'ai un doute.

méga-

nan mais logiquement les API sérieuses ne font pas ce genre de chose. Le driver jdbc postgres fait logiquement partie de cette catégorie ...

 
j'avais pas compris que vous aviez compris... je croyais que vous gueuliez sur celui qui pose la question avant d'essayer de comprendre, comme le font beaucoup ici  
gomen  
 

 
justement, ça peut être sympa de prévenir l'utilisateur qu'il ne peut pas se connecter pour l'instant parce qu'il n'y a plus de place... quand le nombre d'utilisateur est limité à 50 pour des raisons de ressources, et que ce nombre est fréquemment atteint, ça peut être utile non ?

 
Avec les développements open source, c'est pas toujours sérieux

 
roooh mais ta gueule avec tes trolls pourris

 
moins moins staÿle

comme j'en vois tous les jours ici, je me doute bien que ça doit aussi être courant ailleur. Je suis même convaincu que certains ont ça dans leurs templates de catch().

bon ça tourne au pugilas, et puis on est à 300 bornes du problème initial... ma soluce crade marche, donc c'est pas la peine de vous battre pour rien...

ben non, tu peux rien faire !
ex.getMessage()
 
Apres, t'es emmerdé parce que le message est en anglais, mais là on en revient a l'eternel probleme de la traduction des messages d'exception, auquel il n'y pas de solution standard

ps: http://java.sun.com/j2se/1.3/docs/ [...] rrorCode()
 
avec le code d'exception spécifique à la db et des fichiers de resources pour les trads des messages qui t'interesse, tu te demerdes

 
bah si, j'ai fait

Quelle solution ??
 
Déjà que je comprends pas quel est ton problème ...
 
je cite :  

Le fait est que c'est une exception et que tu fais un catch (normal).
 
Donc, c'est quoi ton problème ????

la ou ca va être beau, c'est si le message change a la prochaine release  

 
Ca me rapelle un bug du plugin CVS dans eclipse

ca me rappelle a moi que c'est mal d'utiliser les toString() des nodes en xml au lieu de getNodeValue()

 
c'est la dernière release pour postgresql 7.3  
les autres sont pour postgresql 7.4 et 7.5...
je vais essayer de tester avec le getErrorCode, mais vu que c'est nulle part dans la doc du driver, je suis pas sûr qu'ils s'en servent...
 
enfin, à utilisation d'un driver crade, solution crade non ?  
et puis j'ai mis une tâche pour pas perdre cet endroit de vu...

j'avais pas vu
 
T'as vérifié que le type excate de l'exception n'est pas une sous exception de SQLException ?

c'est daill'eurs probablement une PGSQLException

 
Essai de catcher un Throwable au lieu de Exception,
c'est un cran au-dessus dans la hiérérchie des classes.
 
En général il faut les laisser passer car c'est des erreurs graves.

 
= > Pas de problème de maintenance, et respect total de l'utilisateur.