http://mvnrepository.com/ ?
162.000 librairies qui n'attendent que toi…
Toutes disponibles en 4 lignes de XML dans le POM.
http://mvnrepository.com/ ?
162.000 librairies qui n'attendent que toi…
Toutes disponibles en 4 lignes de XML dans le POM.
http://mvnrepository.com/ ?
162.000 librairies qui n'attendent que toi…
Toutes disponibles en 4 lignes de XML dans le POM.
C'est quoi l'IoC ?
Ça fait parti du langage où c'est un hack à base de manipulation de
byte code / aop et ces sortes de choses ?
Comment on fait quand ça marche pas ?
C'est quoi l'IoC ?
Ça fait parti du langage où c'est un hack à base de manipulation de
byte code / aop et ces sortes de choses ?
Comment on fait quand ça marche pas ?
C'est quoi l'IoC ?
Ça fait parti du langage où c'est un hack à base de manipulation de
byte code / aop et ces sortes de choses ?
Comment on fait quand ça marche pas ?
Oui mais quelle est la pérénité de ces dépots et quel est le niveau de
sécurité ?
Oui mais quelle est la pérénité de ces dépots et quel est le niveau de
sécurité ?
Oui mais quelle est la pérénité de ces dépots et quel est le niveau de
sécurité ?
La première fois que tu executes une cible ça download un tas de trucs
dont tu ignores à quoi ça peut bien servir.
Je suis vraiment pas convaincu par Maven mais j'ai peut-être pas tout
compris.
La première fois que tu executes une cible ça download un tas de trucs
dont tu ignores à quoi ça peut bien servir.
Je suis vraiment pas convaincu par Maven mais j'ai peut-être pas tout
compris.
La première fois que tu executes une cible ça download un tas de trucs
dont tu ignores à quoi ça peut bien servir.
Je suis vraiment pas convaincu par Maven mais j'ai peut-être pas tout
compris.
quel est le niveau de sécurité ?
quel est le niveau de sécurité ?
quel est le niveau de sécurité ?
Le Sat, 18 Jun 2011 19:59:47 +0200,
Aéris écrivait :
>
> Le 18/06/2011 19:50, JKB a écrit :
>> Pas exactement. Mais si tu ne vois pas la différence, tant
>> pis.
>
> J'ai très bien compris.
> Rien ne t'empèche de traiter localement ta libération de mémoire
> puis de remonter l'erreur pour faire la reprise.
>
> void doBordel() {
> int[INT_MAX] grosDawa = …
> try {
> trucQuiPlante();
> } finally {
> free(grosDawa);
> }
> }
>
> propre, net, précis et sans bavure.
Non. Va jusqu'au bout de ton raisonnement. Cela implique de
récupérer le code d'erreur localement, puis de traiter ce
qu'il faut localement,
puis de remonter l'erreur (soit avec un code
d'erreur, soit avec une exception et un magnifique throw)
à la
fonction appelante, et ainsi récursivement jusqu'à un point où tu
peux prendre ta décision sur le traitement à apporter. Je n'ai
_jamais_ vu un code Java (ou C++ d'ailleurs) fonctionner comme ça. Je
ne dis pas que ça n'existe pas, simplement que je n'en ai jamais vu.
La plupart du temps, tu as un try/catch avec un gros machin pas net
dedans qui récupère toutes les exceptions qui passent, se
contrefichant éperdument de tout ce qu'il faudrait récupérer
correctement.
Le Sat, 18 Jun 2011 19:59:47 +0200,
Aéris <aeris@imirhil.fr> écrivait :
>
> Le 18/06/2011 19:50, JKB a écrit :
>> Pas exactement. Mais si tu ne vois pas la différence, tant
>> pis.
>
> J'ai très bien compris.
> Rien ne t'empèche de traiter localement ta libération de mémoire
> puis de remonter l'erreur pour faire la reprise.
>
> void doBordel() {
> int[INT_MAX] grosDawa = …
> try {
> trucQuiPlante();
> } finally {
> free(grosDawa);
> }
> }
>
> propre, net, précis et sans bavure.
Non. Va jusqu'au bout de ton raisonnement. Cela implique de
récupérer le code d'erreur localement, puis de traiter ce
qu'il faut localement,
puis de remonter l'erreur (soit avec un code
d'erreur, soit avec une exception et un magnifique throw)
à la
fonction appelante, et ainsi récursivement jusqu'à un point où tu
peux prendre ta décision sur le traitement à apporter. Je n'ai
_jamais_ vu un code Java (ou C++ d'ailleurs) fonctionner comme ça. Je
ne dis pas que ça n'existe pas, simplement que je n'en ai jamais vu.
La plupart du temps, tu as un try/catch avec un gros machin pas net
dedans qui récupère toutes les exceptions qui passent, se
contrefichant éperdument de tout ce qu'il faudrait récupérer
correctement.
Le Sat, 18 Jun 2011 19:59:47 +0200,
Aéris écrivait :
>
> Le 18/06/2011 19:50, JKB a écrit :
>> Pas exactement. Mais si tu ne vois pas la différence, tant
>> pis.
>
> J'ai très bien compris.
> Rien ne t'empèche de traiter localement ta libération de mémoire
> puis de remonter l'erreur pour faire la reprise.
>
> void doBordel() {
> int[INT_MAX] grosDawa = …
> try {
> trucQuiPlante();
> } finally {
> free(grosDawa);
> }
> }
>
> propre, net, précis et sans bavure.
Non. Va jusqu'au bout de ton raisonnement. Cela implique de
récupérer le code d'erreur localement, puis de traiter ce
qu'il faut localement,
puis de remonter l'erreur (soit avec un code
d'erreur, soit avec une exception et un magnifique throw)
à la
fonction appelante, et ainsi récursivement jusqu'à un point où tu
peux prendre ta décision sur le traitement à apporter. Je n'ai
_jamais_ vu un code Java (ou C++ d'ailleurs) fonctionner comme ça. Je
ne dis pas que ça n'existe pas, simplement que je n'en ai jamais vu.
La plupart du temps, tu as un try/catch avec un gros machin pas net
dedans qui récupère toutes les exceptions qui passent, se
contrefichant éperdument de tout ce qu'il faudrait récupérer
correctement.
Le 19/06/2011 09:42, JKB a écrit :Foutaise. Elle est obligatoire lors de l'édition des liens et de
l'exécution. Si tu ne peux pas résoudre les symboles lors de
l'édition des liens, tu risques fort de ne pas obtenir
d'exécutable.
Ben je ne sais pas comment vous avez gaulé votre bordel en C/C⁺⁺ mais
Java s'en sort très bien dans ce cas là =)
Je peux avoir un .jar executable compilé avec une certaine librairie et
je n'ai absolument pas besoin du .jar de ma lib à l'exécution tant que
je n'ai pas besoin d'une seule de ses classes.
À la limite je peux même lancer mon jar sans la lib, mettre la lib
après-coup, et sans redémarrer l'exe, me mettre à utiliser ses classes.
Le 19/06/2011 09:42, JKB a écrit :
Foutaise. Elle est obligatoire lors de l'édition des liens et de
l'exécution. Si tu ne peux pas résoudre les symboles lors de
l'édition des liens, tu risques fort de ne pas obtenir
d'exécutable.
Ben je ne sais pas comment vous avez gaulé votre bordel en C/C⁺⁺ mais
Java s'en sort très bien dans ce cas là =)
Je peux avoir un .jar executable compilé avec une certaine librairie et
je n'ai absolument pas besoin du .jar de ma lib à l'exécution tant que
je n'ai pas besoin d'une seule de ses classes.
À la limite je peux même lancer mon jar sans la lib, mettre la lib
après-coup, et sans redémarrer l'exe, me mettre à utiliser ses classes.
Le 19/06/2011 09:42, JKB a écrit :Foutaise. Elle est obligatoire lors de l'édition des liens et de
l'exécution. Si tu ne peux pas résoudre les symboles lors de
l'édition des liens, tu risques fort de ne pas obtenir
d'exécutable.
Ben je ne sais pas comment vous avez gaulé votre bordel en C/C⁺⁺ mais
Java s'en sort très bien dans ce cas là =)
Je peux avoir un .jar executable compilé avec une certaine librairie et
je n'ai absolument pas besoin du .jar de ma lib à l'exécution tant que
je n'ai pas besoin d'une seule de ses classes.
À la limite je peux même lancer mon jar sans la lib, mettre la lib
après-coup, et sans redémarrer l'exe, me mettre à utiliser ses classes.
Le Sat, 18 Jun 2011 18:16:30 +0000 (UTC)
JKB a écrit :Le Sat, 18 Jun 2011 19:59:47 +0200,
Aéris écrivait :
>
> Le 18/06/2011 19:50, JKB a écrit :
>> Pas exactement. Mais si tu ne vois pas la différence, tant
>> pis.
>
> J'ai très bien compris.
> Rien ne t'empèche de traiter localement ta libération de mémoire
> puis de remonter l'erreur pour faire la reprise.
>
> void doBordel() {
> int[INT_MAX] grosDawa = …
> try {
> trucQuiPlante();
> } finally {
> free(grosDawa);
> }
> }
>
> propre, net, précis et sans bavure.
Non. Va jusqu'au bout de ton raisonnement. Cela implique de
récupérer le code d'erreur localement, puis de traiter ce
qu'il faut localement,
En général on ne sait pas quoi faire localement.
puis de remonter l'erreur (soit avec un code
d'erreur, soit avec une exception et un magnifique throw)
S'il n'y a pas de catch mais seulement un finally, il n'y a même pas
besoin de propager l'exception : le code de nettoyage dans le bloc
finally est exécuté puis l'exception est automatiquement propagée.
à la
fonction appelante, et ainsi récursivement jusqu'à un point où tu
peux prendre ta décision sur le traitement à apporter. Je n'ai
_jamais_ vu un code Java (ou C++ d'ailleurs) fonctionner comme ça. Je
ne dis pas que ça n'existe pas, simplement que je n'en ai jamais vu.
La plupart du temps, tu as un try/catch avec un gros machin pas net
dedans qui récupère toutes les exceptions qui passent, se
contrefichant éperdument de tout ce qu'il faudrait récupérer
correctement.
En Java, la plupart du temps il n'y a rien à récupérer "correctement".
Seulement de la mémoire, mais tout ce qui a été alloué dans la fonction
et stocké dans des variables locales n'a pas besoin d'être récupéré
(comme dans le cas d'une fin normale de la fonction, c'est le
collecteur de mémoire qui s'en occupe).
Dans le cas où il a des choses à récupérer (fichiers, ...), en général
il y a une exception à gérer explicitement (IOException, ...). Donc
l'obligation de réfléchir à ce qu'il faut en faire (moins facile à
oublier qu'un code d'erreur).
Le Sat, 18 Jun 2011 18:16:30 +0000 (UTC)
JKB <jkb@koenigsberg.invalid> a écrit :
Le Sat, 18 Jun 2011 19:59:47 +0200,
Aéris <aeris@imirhil.fr> écrivait :
>
> Le 18/06/2011 19:50, JKB a écrit :
>> Pas exactement. Mais si tu ne vois pas la différence, tant
>> pis.
>
> J'ai très bien compris.
> Rien ne t'empèche de traiter localement ta libération de mémoire
> puis de remonter l'erreur pour faire la reprise.
>
> void doBordel() {
> int[INT_MAX] grosDawa = …
> try {
> trucQuiPlante();
> } finally {
> free(grosDawa);
> }
> }
>
> propre, net, précis et sans bavure.
Non. Va jusqu'au bout de ton raisonnement. Cela implique de
récupérer le code d'erreur localement, puis de traiter ce
qu'il faut localement,
En général on ne sait pas quoi faire localement.
puis de remonter l'erreur (soit avec un code
d'erreur, soit avec une exception et un magnifique throw)
S'il n'y a pas de catch mais seulement un finally, il n'y a même pas
besoin de propager l'exception : le code de nettoyage dans le bloc
finally est exécuté puis l'exception est automatiquement propagée.
à la
fonction appelante, et ainsi récursivement jusqu'à un point où tu
peux prendre ta décision sur le traitement à apporter. Je n'ai
_jamais_ vu un code Java (ou C++ d'ailleurs) fonctionner comme ça. Je
ne dis pas que ça n'existe pas, simplement que je n'en ai jamais vu.
La plupart du temps, tu as un try/catch avec un gros machin pas net
dedans qui récupère toutes les exceptions qui passent, se
contrefichant éperdument de tout ce qu'il faudrait récupérer
correctement.
En Java, la plupart du temps il n'y a rien à récupérer "correctement".
Seulement de la mémoire, mais tout ce qui a été alloué dans la fonction
et stocké dans des variables locales n'a pas besoin d'être récupéré
(comme dans le cas d'une fin normale de la fonction, c'est le
collecteur de mémoire qui s'en occupe).
Dans le cas où il a des choses à récupérer (fichiers, ...), en général
il y a une exception à gérer explicitement (IOException, ...). Donc
l'obligation de réfléchir à ce qu'il faut en faire (moins facile à
oublier qu'un code d'erreur).
Le Sat, 18 Jun 2011 18:16:30 +0000 (UTC)
JKB a écrit :Le Sat, 18 Jun 2011 19:59:47 +0200,
Aéris écrivait :
>
> Le 18/06/2011 19:50, JKB a écrit :
>> Pas exactement. Mais si tu ne vois pas la différence, tant
>> pis.
>
> J'ai très bien compris.
> Rien ne t'empèche de traiter localement ta libération de mémoire
> puis de remonter l'erreur pour faire la reprise.
>
> void doBordel() {
> int[INT_MAX] grosDawa = …
> try {
> trucQuiPlante();
> } finally {
> free(grosDawa);
> }
> }
>
> propre, net, précis et sans bavure.
Non. Va jusqu'au bout de ton raisonnement. Cela implique de
récupérer le code d'erreur localement, puis de traiter ce
qu'il faut localement,
En général on ne sait pas quoi faire localement.
puis de remonter l'erreur (soit avec un code
d'erreur, soit avec une exception et un magnifique throw)
S'il n'y a pas de catch mais seulement un finally, il n'y a même pas
besoin de propager l'exception : le code de nettoyage dans le bloc
finally est exécuté puis l'exception est automatiquement propagée.
à la
fonction appelante, et ainsi récursivement jusqu'à un point où tu
peux prendre ta décision sur le traitement à apporter. Je n'ai
_jamais_ vu un code Java (ou C++ d'ailleurs) fonctionner comme ça. Je
ne dis pas que ça n'existe pas, simplement que je n'en ai jamais vu.
La plupart du temps, tu as un try/catch avec un gros machin pas net
dedans qui récupère toutes les exceptions qui passent, se
contrefichant éperdument de tout ce qu'il faudrait récupérer
correctement.
En Java, la plupart du temps il n'y a rien à récupérer "correctement".
Seulement de la mémoire, mais tout ce qui a été alloué dans la fonction
et stocké dans des variables locales n'a pas besoin d'être récupéré
(comme dans le cas d'une fin normale de la fonction, c'est le
collecteur de mémoire qui s'en occupe).
Dans le cas où il a des choses à récupérer (fichiers, ...), en général
il y a une exception à gérer explicitement (IOException, ...). Donc
l'obligation de réfléchir à ce qu'il faut en faire (moins facile à
oublier qu'un code d'erreur).
Si, libérer les ressources utilisées dans la fonction dans laquelle
la fonction fautive a été appelée. Et il faut le faire récursivement
jusqu'à la fonction dans laquelle on peut traiter l'erreur. Si tu ne
fais pas ça, tu risques fort d'avoir des fuites de mémoire un peu
partout (voire pire).
Ah ? Enfin, tout est dans le 'la plupart du temps'...
Sauf que c'est très con. Parce que ton exception peut être récupérée
tout à fait ailleurs et de façon totalement dégueulasse.
Si, libérer les ressources utilisées dans la fonction dans laquelle
la fonction fautive a été appelée. Et il faut le faire récursivement
jusqu'à la fonction dans laquelle on peut traiter l'erreur. Si tu ne
fais pas ça, tu risques fort d'avoir des fuites de mémoire un peu
partout (voire pire).
Ah ? Enfin, tout est dans le 'la plupart du temps'...
Sauf que c'est très con. Parce que ton exception peut être récupérée
tout à fait ailleurs et de façon totalement dégueulasse.
Si, libérer les ressources utilisées dans la fonction dans laquelle
la fonction fautive a été appelée. Et il faut le faire récursivement
jusqu'à la fonction dans laquelle on peut traiter l'erreur. Si tu ne
fais pas ça, tu risques fort d'avoir des fuites de mémoire un peu
partout (voire pire).
Ah ? Enfin, tout est dans le 'la plupart du temps'...
Sauf que c'est très con. Parce que ton exception peut être récupérée
tout à fait ailleurs et de façon totalement dégueulasse.
Certes. Mais pour compiler ton jar, chez moi, il faut toutes les
bibliothèques.
Certes. Mais pour compiler ton jar, chez moi, il faut toutes les
bibliothèques.
Certes. Mais pour compiler ton jar, chez moi, il faut toutes les
bibliothèques.
