Reprise du message précédent :
oui

putain la citation

c en hommage à Pierre Tramo
 
là ce serait plutot J2EE developper en apprentissage

ça n'inspire personne?
 
(la méthode ci-dessus marche, mais à tendance à faire explorer le profiler quand la charge monte)

ouais comme ca, sauf que tu gères bizarement tes exceptions ...

nab, en fait c'est pas top
j'arrive pas à reflechir ce matin

 
+1, j'osais pas demander... je comprends pas trop

dans un bloc finally, dans le cas où une exception a été lancée, y a moyen de le savoir et éventuellement de la récupérer ?
 
parce que j'arrive pas à faire une gestion d'exception parfaite sans ca
 
je bloque sur 2 mauvaise solutions :  
* le catch (la version que j'ai écrit au dessus :  si writeObject() balance une Runtime, ca ferme pas le flux Et si pour éviter ca je catch Throwable, déjà c'est mal, mais en plus je ne peux plus balancer l'exception parce que ca colle plus avec la clause throws y a la possibilité de tester la classe de l'exception (io, runtime, error, mais c'est trop laid !)
* le finally mais si le close crache une exception, on perd l'éventuelle exception lancée dans le try

benou > tu comptes tenter de fermer un flux qui a déjà craché une exception ?

bha oui vaut mieux ...

selon quel principe ?

en fait dans l'idéal faudrait un truc comme ca :  
 

ben la libération de ressource ...
 
exemple : tu es en train de lire le contenu d'un fichier. ca plante (prb temporaire d'accès au fichier, outofmemory, etc.), si je close pas après, ca liberera pas le lock sur le fichier
 
pkoi tu penses qu'il faut pas closer ? je comprends pas là ...

ben soit le problème est circonscrit finement et on sait l'état du fichier et cet état n'est pas incompatible avec une fermeture, soit on a un IOExcpetion et on aaucune idée du pb, ou alors on sait finement le pb, mais on sait qu'il nous empêchera de fermer, et là on y touche plus.

bha dans le pire des cas, au close ca te recrache une IO ... spagrave ... mais je vois pas pkoi ne pas tenter de closer

parce que tu n'as aucune idée de la sémantique du close, que si c'est plus ou moins transactionné en-dessous, pas la peine de committer des conneries, et que le close lui-même a toutes les chances de foirer, et t'as pas l'air con avec tes 2 exceptions (celle de l'opération et celle du close) à remonter dans un seul tuyau (encore que tu es sensé wrapper au niveau métier, tu peux donc en mettre une dans la cause, et celle du close dans une variable d'instance).

ben si y a une exception, le close a qu'à pas faire de commit ... c'est à lui de voir ...
 
sérieux tu ferais quoi toi ? ca ?  

voyons benou, sois raisonnable, ton stream, tu es tout seul à le voir et il ne représente pas une ressource physique => pas de close.
 
D'autre part cette clause throws n'a rien à foutre là, le client il en a rien à battre que tu utilises un Stream ou un chausse-pied pour faire rentrer ton objet dans un tableau d'octets.
 
Dans ce cas, c'est clair -> wrapping dans une runtime exception, si un bout de code aussi bateau plante, c'est que l'heure est très grave.

bha non, ca peut planter très facilement si l'objet contient un objet non sérializable
 
puis bon, pour le close, je parlais dans le cas générale ...
 
sinon t'as vu ma question sur le finally ? tu sais si c'est faisable de récupérer l'exception courante ?

c'est pas moi hein

putain mais on s'en bat les couilles de la gestion d'exception dans ce bout de code, c'est pas ça le problème

non, c'est pas faisable. Tu n'a qu'à la mettre dans une variable dans le catch et aller lire la variable dans le finally.

oui, mais c'est une erreur en rapport avec le métier.  
Et puis d'abord tu n'as qu'à typer ta fonction par Serializable.

ca changera rien si c'est un objet contenu dans l'objet qui l'est pas ...

 
ouais mais ca me va pas : faudrait que je catch Throwable et je ne peux pas relancer une Throwable (clause throws = IO)
 
nul que ce soit pa faisable

ON S'EN FOUT DES EXCEPTIONS DANS MON TRUC!!!!

ben quoi alors ? tu sais pas sérialiser un objet ?

ah oui tiens.
Mais c'est pas grave là c'est une exception du domaine, c'est déclarable en throws.

c'est quelle ligne qui bouffe le temps d'exécution ?
le profil de mémoire dit quoi pendant le pic ?
qui a fait le code de sérialisation ?
peut-tu estimer à l'avance la taille finale du tableau d'octets ?

tain mais oscour, tu souffres d'ADD?
 

 
je cherche un truc optimisé au poil de cul près.

quand vous aurez fini de vous branler la nouille sur la gestion d'exception minable:
http://www.theserverside.com/news/ [...] d_id=23485

  hein ?
 
 
qu'est ce que tu faire de plus optimizé que ca ? y a pas 36 façons de sérialiser un objet

 
faut sortir, de temps en temps

je parlais de la sérialisation du JDK ... c'est celle là que tu utilises dans ton exemple non ?
 
Si ce que tu veux c'est d'autres API de sérialization dis le clairement !

mais peu importe, je cherche un truc qui marche mieux, c'est tout.
déjà le machin qui fait le toByteArray() sur le stream, il sent le paté.
ensuite, détail qui à son importance, je dois pas sérializer des objets arbitrairement, mais un graphe plus ou moins non-arbitraire (ie, il se pourrait que des objets "inconnus" arrivent dans une map, par exemple, mais ça devrait pas etre le cas chez nous)

fais pêter le code, réponds à mes questions, file-nous le profil.

le toByteArray fais une copie du tableau de Byte.
 
Si tu veux éviter cette copie, ne passe pas par un byte[], passe par un stream. J'avais filé le code d'une classe  ByteArrayStream que j'avais fait qui permettait de récupérer un InputStream depuis un objet genre ByteArrayOutputStream : ca évite de recréer un tableau de byte inutile
 
y a moyen de faire ca avec des classes de java.io (les Piped machin) mais c'est déconseillé dans un environnement multithreadé je crois ...

 
z'avez déja joué avec javahelp ?

benou >> en sortie, pour l'instant, j'ai pas vraiment le choix, l'objet est serialisé en base par l'intermediaire d'un ejb, et les champs de type *Stream, ça marchait pas fort la derniere fois que j'ai essayé.
 
sinon bah va sans doute falloir implementer les readObject et writeObject, ça risque d'etre un poil lourd, et personne à jamais fait ça chez nous, à mon avis.
(si y'en a un qui l'a fait, c'etait surement mauvais )
 
nraynaud > j'ai pas vu de question; le code tu l'as, si tu veux le code des objets à serializé, c'est la WorkingMemory de drools, et le profil, euh pête pas les couilles. Tout ce que je sais pour l'instant c'est que y'a genre 80% du process qu'on testait vendredi qui etait passé dans la methode mentionnée ci-dessus. j'ai pas profilé moi meme, j'ai juste maté l'ecran de mon collegue

tiens, il parraît que la nouvelle application de Mentor Graphics est en java. Je suis pas sûr parce que c'est le commercial qui me l'a dit, et que ça ressemblait étrangement à MS Visual studio dans l'esprit.