Reprise du message précédent :

euh oui mais il parlait des InterruptedException sur wait() et notify() là

heu, tu passes le set de tout ce que tu as déjà rencontré en entrée (le critère c'est si le node dans lequel je rentre est dans le set, alors j'ai une boucle), et en déroulant la pile lors de la remontée d'exception, tu signales par où tu es arrêté.
 
y'a que 2 algos de détection de cycles hein

Moi je parlais à 0x90, qui lui ne parlait pas des wait/notify.

heureusement que ceux qui ont conçu java sont pas aussi extremiste que toi : j'avais pas envie de devoir catcher NullPointerException et OutOfMemoryError à chaque appel de méthode
 

nan, ca c'est la composition (c'est la différence du losange blanc et du losange noir en UML (je sais jamais lequel est la composition et l'autre l'agrégation   ))
 

ben un format incorrect c'est vachement pas exceptionnel. c'est un cas normal à traiter.
 
tu veux parler de quoi alors ? donne un exemple ...

 

ha, tu parlais d'une unchecked exception à utiliser "hors des situations exceptionnelles"
 
 

y a pire : après avoir catché une InterruptedException, que dois-je faire pour indiquer que je souhaite que les Thread continue son interruption ?
ou posé autrement : quel changement d'état le catch d'un InterruptedException provoique-t-il ?
 

tu me surprends ... c'est assez basique dès que tu fais un peu de multithreading ...
 

marrant : c'est à peu près ce que j'ai fait à la mano à coup de Utils.getMandatoryAttribute(Ctx, key) dans le produit que je gère (en bcp moins ouvert, c'est sûr)

ha oui merde j'avais mal vu quel post il avait quoté

Ah oui j'avais pas pensé à la répétitivité à une "distance de profondeur" (je me comprends) > 1.

mais grmf, si A uses B , A forcement has B, aussi, et inversément, non ?
enfin, ché pas, moi j'ai dit "has" parce que aggreger, pour moi, ça veut dire mettre ensemble.
et puis autant en conception uml, on peut vaguement distinguer les 2 concepts, en prog, on peut pas, ou alors je vois pas comment là tt de suite?

oui mais de nos jours, dans 90% des cas, t'as pas a foutre les mains dans le cambouis

1) En même temps, catcher OutOfMemoryError, je connais que JetBrains qui sache faire, perso j'ai déjà essayé, j'ai jamais réussi.
 
2) pareil, et je bosse sur un produit UML en plus maintenant, mais j'ai perdu mes complexes.
 
3) ben justement j'en avais jamais vraiment fait avant d'être forcé.

... je me complete: et hop, ton Action est instanciée avec les dependences qui vont bien qui lui sont passées dans le constructeur. jpeux plus m'en passer perso
(ça et le "remplissage" de mes actions ou beans à partir des params de la request, plutot que de me taper des milliers de req.getParam et les conversions de types qui suivent )

Yep, mais conceptuellement, vaut mieux l'avoir en tête, la différence, quand même.
 
Sur ces belles paroles... a+

ben si : pour moi, composition c'est quand la via de B est liée à celle de A. En gros, quand A construit B pour s'en servir et que B n'est utilisé que par A (je parle d'instance, pas de classes) et que quand A est détruit, B l'est aussi. Par contre aggrégation c'est quand B est utilisé par A, mais aussi potentiellement par d'autres objets. la mort de A ne signifit pas la mort de B.
c'est la différence entre posséder et utiliser.  (comme un couple marrié très soudé et un couple libertain quoi )

perso je m'e fous, mon éditeur me dit tout seul si je peux mettre le mot clef 'final' ou pas à un champ.

ha oui je vois merci

ca dépend peut être ce que tu fais ... moi c'est généralement côté serveur, et là c'est vraiment pas rare d'y être confronté. (encore faut-il s'en rendre compte    )
edit : "pas rare", j'exagère peut être un peu ...  
 

 
1) ha ben si, ca se fat assez bien si t'es assez haut dans la pile (de façon à ce que ta mémoire ait été libérée au moment du catch).  
3) ben bonne chance   ... remarque, vu la façon dont t'es carré dans ta conception des choses, tu t'en sortiras avec bcp moin de douleurs que d'autres...  
 

c'est clair que c'est vraiment beaucoup plus confortable un objet correctement initialisé et utilisable dès la sortie du constructeur... le coup des setMachin() à faire après pour que l'objet puisse être utilisé, je peux plus ... c'est pour ça que le type 2 me fait
 
edit : oups, je viens de bien comprendre ce que tu disais ... je serai curieux de voir un exemple de code utilisant ce truc parce que j'ai un peu de mal à me rendre compte de ce que ça donne à l'usage ...
par exemple : où est ce que tu fais l'association entre les dépendances que tu as déclaré et l'appel du constructeur de ton Action avec ses différents paramètres (correspondant au constructeur). C'est quand même pas de l'invocation dynamique ?
 

tu le fais avec quoi ça ? pico aussi ?    
 

spamal ca tient
 
tiens, en passant : un truc que je regrette sur final c'est que même dans le constructeur tu n'as le droi d'affecter qu'une fois l'attribut.

pareil, mais les mecs de spring sont braqués sur l'SDI (type2) :\ (le CDI est supporté par spring aussi mais apparement pas trop promu... i sont bizarres ces gens là)
 

non, en l'occurence c'est webwork qui s'en charge; mais pico est aussi capable d'instancier un objet et de faire du SDI ou d'appeler des setters bean-style dessus s'il faut

on exporte les modèles de together, là ça parle de XMI, mais je sais quel est le modeleur derrière.

je copie là parce que sinon tu risques de pas le voir:
 

ben si c'est de l'invocation dynamique !?
 
bon, dans le cas d'un truc web avec webwork, y'a plusieurs concepts à intégrer, mais en gros
requete http sur /pouet/truc.action?foo=bar :  
1. webwork recoit la requete, et sait pouet/truc.action est mappé sur com.machin.pouet.TrucAction
2. webwork (sans que j'y fasse rien, moi, c le framework qui s'en occupe, quoi) demande à pico (enfin, en l'occurence à sa Factory que j'ai config pour etre une instance de la factory qui utilise pico) de lui filer une TrucAction
3. pico se démerde, instancie TrucAction avec les dependences qui vont bien, puis  
4. webwork populationnes (uh) l'action ou le model y attaché (peu importe) avec les eventuels param du formulaire, set-style ( action.setFoo("bar" ) )
5. webwork appelle la methode execute() (ou autre méthode suivant la config, le mapping, bref) de TrucAction
6. Et bah là j'ai plus qu'a coder ma ptite logique business avec les params qui vont bien et mes dependences sont là
(sachant que mes params sont convertis et validés de manieres transparente)
 
 
edit: en 3, pico se démerde sur base des types qui ont été registrés. par defaut, avec webwork, mes actions sont registrées "on the fly", sans parametres. Donc, soit pico se démerde et tout roule, soit il y a exception parce qu'il peut pas déterminer quel params injecter (soit il ne connait pas un certain type, soit il a plusieurs classes du meme types registrés donc il peut pas determiner lequel injecter) - soit je register mon action (c'est valable pour n'importe quel composant) en spécifiant explicitement quels params je veux que pico lui file (en filant des instances ou des clés à pico)

CUCHACA \OOOOOOOOOOOOOOO_
 
 
 LOLOLOLOLOLOL CUCHACA AVEC LA CEWDILLAE \O_?:

 
 
Ça va bien, trésor ?

Merde. Il a réussi à ouvrir son force 4.

yo

yoyo

WTF
 
C'est quoi cette température ? Il fait meme pas frais

ici il fait frais

Non, mais ça peut être traité aisément de façon propre.
Tu les catches au niveau le plus élevé (donc une seule fois). Pour le 2e, tu affiches un message signalant l'insuffisance de mémoire.
Dans les deux cas, tu signales qu'une erreur grave est arrivée, et que l'app est obligée de quitter. Et là, tu quittes essayes de quitter de façon propre (enregistrement et fermeture des fichiers, libération des connexions, ressources partagées, arrêt de processus fils, etc, tout ça en espérant que ça se passe bien; réfléchir à l'espace mémoire utilisé pour ces opérations en cas OutOf Mem, quitte à réordonner les opérations pour libérer les tâches prenant le moins de mémoire en premier si c'est possible). Si tu ne les catches pas, l'application quitte sans crier gare, et ça n'est pas bcp mieux qu'un crash pur et simple (ce qui arriverait en C++).
 
En code, ça consiste à rajouter, au niveau du main():
catch (OutOfMem) {affiche(error_message_out_of_mem); clean_all;}
catch (...) {affiche(error_message_generic); clean_all;}
 
Bref, c'est pas la mort, et dire que toutes les exceptions doivent être catchées, c'est pas de l'extrémisme, c'est de l'ingéniérie logicielle robuste.

 

j'vais étudier la question.

ça dirait pas de mettre tartramachin sur branlette plutôt ?

 
mieux depuis un bon dodo et 3L d'eau mais toujours la bouche pateuse

Harko
En mattant le topic sur le gus qui veut apprendre la prog, et comme celui-ci a dérivé sur les diplomes, je pensais à toi. Tu n'as jamais pensé que tu pourrais passer devant une commission pour un VAE ?
 
http://www.ac-nice.fr/vae/centre1.htm

si t'as un exemple de code de ça, je prends
et merci pour l'explication ...
 

et tu les délare en throws à chacune de tes méthodes ?
 
et dans ton main, qu'est ce que tu fais si tu te prends un NPE ? tu sais même pas d'où il vient ... donc comment savoir comment le traiter.
Et puis traiter une exception au niveau du main ca sert à rien (à part présenter un message d'erreur à l'utilisateur). Si t'es retourné jusqu'au main, c'est que ton programme s'est bien planté ... et pour le "relancer" correctement, va falloir jouer à madame irma pour imaginer le problème qu'il y a eu (sinon à tous les coups tu retombes sur le même et tu boucles).
 
suffit pas de catcher un exception n'importe où pour la 'traiter de façon propre', faut encore le faire au bon endroit et 'réagir' correctement ...

Probablement déjà passé, mais c'est du grand art!
 
http://thedailywtf.com/forums/thread/82139.aspx

point confiture

Hey d'ailleurs, j'ai manqué une grosse discussion experte hier soir (j'etais allé voir un avion ? non .. un oiseau ? non .... c'etait...) et ce serait sympa de poser des réponses aux questions un peu flippante Genre pour la question "file.exists() ou FileNotFoundException" (ou bien me suis fait avoir et c'est une question sans réponse)

c'était plus une blague par rapport à un débat qu'on avait eu dans un autre thread y a quelques temps et ca avait duré quelques pages