Bonjour,
lorsque je lance le programme, j’ai cette exception :
java.lang.IllegalArgumentException: Cannot set a null TableModel
at javax.swing.JTable.setModel(JTable.java:2868)
at Test.<init>(Test.java:36)
at Test.main(Test.java:141)
je sais pas, mais c’est un peu violent ça :
vaudrait mieux try{}catch {} ou tester si l’objet lu est null, chercher pourquoi et traiter en conséquence.
Si à un moment donné, tu as écrit un model null dans le fichier, tu vas tourner longtemps.
Instancie un model de table, ou une table, en dure, copie le/la dans un fichier de sauvegarde “immuable”, puis teste si l’objet lu dans l’autre fichier sauve.tmp n’est pas null, si oui, récupére le model original dans le premier fic … c’est juste pour pallier à tes phases de développement où tu te retrouves à un moment avec un objet null dans ton fichier.
Quoi que ça m’étonne, de mémoire je pensais qu’on pouvait pas sérialiser un objet null … mais bon … regardes si ton fichier sauve.tmp contient quelquechose non ?
Ouais le cast explicite c’est bien quand tu est certain de ce que tu fais a 100%, mais en général vaut mieux un bon gros bloc try/catch pour encadrer tout ca.
Apres pour le reste du code j’ai pas le temps de le lire mais bon, c’est un peu comme pas vérifier le retour d’un stat en C … tant que ca marche tout va bien, puis a un moment on teste un nouveau truc et tout d’un coup on segfault 
.
Donc code hyper précautionneusement et ca devrait deja te permettre d’isoler la cause. Sinon compiles avec l’option “-Xlint” pour avoir un ptit paquet de warnings en + (très pratique si toi ou une des classes standart utilise la généricité par exemple, pour pas avoir de surprise) si tu ne le fais pas deja.
[quote=“Hoshin”]Ouais le cast explicite c’est bien quand tu est certain de ce que tu fais a 100%, mais en général vaut mieux un bon gros bloc try/catch pour encadrer tout ca.[/quote]Ça c’est pas bon désolé …
normalemnt, déjà, un try catch devrait explicitement donner les exceptions qu’ils gèrent, exemple :
try {}
catch (type1 d’exception){traitement …}
catch (type2 d’exception){traitement …}
catch (type3 d’exception){traitement …}
catch (Exception e){traitement …}
En suite, le cast explicite est obligatoire pour ce genre de truc à mon avis … 
ps: oui on peut le spécifier aussi CastException mais normalement la fonction qui écrit et lit le fichier traite soit un seul type d’objet, soit un objet null … à gérer .
Je parlais pas de bloc monstrueux de try catch pour genre gérer toutes les exceptions, je me suis mal fait comprendre. Car autant ca peut marcher a peu pres correctement si on attrape que peu d’erreurs. Autant pour débugger, et gérer correctement les erreurs il faut effectivement lever toutes les exceptions que le bout de code dans “try” pourrait générer.
Sinon bah y’a des moments ou on est bien obligés de faire des casts je suis d’accord ^^. Je dis juste qu’il faut pas les faire a l’arrache aprceque ca peut tres bien compiler si au niveau héritage ca marche, mais que, a cause de la facon dont on instancie l’objet, il semblerait qu’on pourrait manger des erreurs d’execution, meme en cas de downcast implicite propre avec la bonne relation d’héritage et tout le toutim (On s’est fait dégommer en partiel a cause de ce genre de petites choses par not prof de java a coups de downcast explicites légaux qui passaient la compil’ mais qui foiraient a l’exe ).
Enfin bon mea culpa usine parcequ’apparament je me suis mal exprimé =)
[quote=“Hoshin”]… exe
Enfin bon mea culpa usine parcequ’apparament je me suis mal exprimé =)[/quote]
Et en plus tu dis des gros mots ?! exe ? [size=200].[/size]exe ? quézaco ?!
non bon je m’y remet tout doucement à java, tu es peut-être plus dans le bain que moi (downcast ? quézecé ?). Ceci dit je ne connais pas encore le 1.5, et ses innovations … (connais que le 1.4 un peu bien mais fastidieusement quand même).
Bonjour,
J’ai réussi à coder un programme permettant de garder ce que j’ai tapé dans ma JTable
Comme ça fonctionnait, j’ai intégré un code qui permet de remplir des cases en cliquant dessus.
J’obtiens pleins d’exceptions lorsque je valide ce que j’ai écrit dans la JTable
[quote=“Premium”]
Peut-être que ça serait mieux :
int nbcol = méthode renvoyant le nombre de colonnes ...
for(int ncol =0; ncol<nbcol; ncol++){
Parce que la première colonne est d’indice 0…
[quote=“usinagaz”][quote=“Premium”]
Peut-être que ça serait mieux :
int nbcol = méthode renvoyant le nombre de colonnes ...
for(int ncol =0; ncol<nbcol; ncol++){
Parce que la première colonne est d’indice 0…[/quote]
Je démarre à 1 car je ne veux pas que cette colonne soit éditable.
J’ai mis 0 pour voir mais les exceptions sont toujours présentes lorsque je valide
Je suis désolé Premium, mais je vais pas pouvoir plus t’aider, j’ai moi-même mes propres élucubration javanesques et bashesques à débuguer, et ce que tu demandes , c’est un peu avoir la science infuse, où pouvoir faire des choses compliquées avec un minimum de connaissances …
Pourtant je peux encore te dire ceci :
t’es tu donné la peine de lire la classe [size=117]NotSerializableException[/size] dans l’api java ?
Tu essaies probablement d’écire un objet qui ou dont un des champs n’implemente pas sérializable … petit rappel, les champs private, ou peut être les types simples, ne sont pas sérializables, ces derniers n’étant pas des objets, mais je suis pas sur de tout ça.
Donc tu prends l’objet que tu tentes de sérialiser, tu regardes s’il implémente sérializable, si oui, tu regardes si tous les champs qui le composent (par agrégation) implémentent serializable … parce qu’il y en a au moins un qui ne le fait pas, ça me semble clair.
@usinagaz : le downcast c’est quand, par exemple, t’as 2 classes A et B avec B qui hérite de A, tu instancies un objet A et ensuite tu le caste en B en faisant (B)ton_objet. L’upcast c’est dans l’autre sens . Bon apres nous on appelle ca comme ca en cours … toi t’as certainement un autre nom plus clair mais nous on prefere suivre le prof au niveau voca au moins le temps qu’il nous note =).
Sinon désolé pour les gros mots j’ai de mauvaises habitudes en termes de voca et surtout je fais trop de C par rapport au java (disons que ca m’intéresse plus vu notre programme).
Ensuite premium, la javadoc est ton amie comme le dit usinagaz m’enfin la a priori je dirais que t’as voulu aller trop vite et que tu t’es passé de certains tests qui maintenant que tu as un peu avancé dans ton prog font tout planter.
ah oui ok Hoshin …
Premium, attention aussi que à chaque fois que tu modifies ta classe d’une virgule, et que tu la recompile, la fonction qui va lire l’instance de cette classe dans le fichier ne comprend plus rien, car c’est plus la même classe (une virgule en moins ou en plus). C’est pourquoi tu dois prévoir un bloc qui initialise une instance en dur de ton objet tel que tu le veux à l’origine. Dés qu’il est initialisé, tu le fais écrire dans le fichier (en écrasant l’ancien) et tu pourra relire ton fichier, les classes correspondront du coup.
j’ai modifié mon code qui ne donne plus les nombreuses exceptions.
Je peux te répondre sur le premier bloc de code que tu donne en exemple :