Oui. Parce que c'est la seule façon d'avoir un truc fiable. Ton
exception est traitée en dehors de la fonction
pire, avec une
ribambelle et demi de fonctions appelées entre la chose qui a levé
ton exception et sa récupération.
Au hasard :
int ma_fonction_qui_renvoie_une_erreur(paramètres d'entrée,
*paramètres de sortie).
Arrête de ne pas regarder plus loin que le bout de ton nez. Je te
prends un exemple tout bête, un shell un peu spécial. S'il n'a plus
de mémoire disponible, il est de bon ton qu'il écrive sur stdout
"not enough memory" ou quelque chose du même genre en retournant une
invite (et au passage en libérant la mémoire qu'il était en train
d'utiliser pour essayer d'exécuter la dernière requête) et non en
segfaultant.
Oui. Parce que c'est la seule façon d'avoir un truc fiable. Ton
exception est traitée en dehors de la fonction
pire, avec une
ribambelle et demi de fonctions appelées entre la chose qui a levé
ton exception et sa récupération.
Au hasard :
int ma_fonction_qui_renvoie_une_erreur(paramètres d'entrée,
*paramètres de sortie).
Arrête de ne pas regarder plus loin que le bout de ton nez. Je te
prends un exemple tout bête, un shell un peu spécial. S'il n'a plus
de mémoire disponible, il est de bon ton qu'il écrive sur stdout
"not enough memory" ou quelque chose du même genre en retournant une
invite (et au passage en libérant la mémoire qu'il était en train
d'utiliser pour essayer d'exécuter la dernière requête) et non en
segfaultant.
Oui. Parce que c'est la seule façon d'avoir un truc fiable. Ton
exception est traitée en dehors de la fonction
pire, avec une
ribambelle et demi de fonctions appelées entre la chose qui a levé
ton exception et sa récupération.
Au hasard :
int ma_fonction_qui_renvoie_une_erreur(paramètres d'entrée,
*paramètres de sortie).
Arrête de ne pas regarder plus loin que le bout de ton nez. Je te
prends un exemple tout bête, un shell un peu spécial. S'il n'a plus
de mémoire disponible, il est de bon ton qu'il écrive sur stdout
"not enough memory" ou quelque chose du même genre en retournant une
invite (et au passage en libérant la mémoire qu'il était en train
d'utiliser pour essayer d'exécuter la dernière requête) et non en
segfaultant.
Il y a pourtant des choses très bien en C.> ou du web en
> C/C⁺⁺ !
Idem.
Il y a pourtant des choses très bien en C.
> ou du web en
> C/C⁺⁺ !
Idem.
Il y a pourtant des choses très bien en C.> ou du web en
> C/C⁺⁺ !
Idem.
Le 18/06/2011 19:18, JKB a écrit :Oui. Parce que c'est la seule façon d'avoir un truc fiable. Ton
exception est traitée en dehors de la fonction
Non, elle est traitée dans la fonction.
En tout cas si je sais faire une reprise sur erreur.
Sinon, je ne fais rien du tout et me contente de propager l'erreur,
jusqu'à ce que quelqu'un sache faire une reprise sur erreur.
pire, avec une
ribambelle et demi de fonctions appelées entre la chose qui a levé
ton exception et sa récupération.
Je ne suis pas toujours capable de prendre une décision sur comment
gérer mon erreur juste au moment où je détecte l'erreur.
Parfois, c'est seulement plusieurs couches au-dessus que je serais
capable de décider quoi faire.
Exemple tout con, une interface pour gérer des fichiers.
Localement je n'ai absolument aucune idée de comment faire une reprise
sur erreur si ma lecture échoue. Dois-je retenter ? Lire à un autre
emplacement ? Ne pas tenir compte de l'erreur ? Seule la couche du
dessus pourra et devra prendre cette décision.
Dans l'interface, toutes les méthodes vont donc lever potentiellement
une IOException, que la couche du dessus devra traiter suivant le cas
(AccessException = on peut sûrement retenter, InvalidFileException = le
chemin est mauvais, SocketClosedException = le réseau me permettant
d'accéder à mon fichier distant est mort…).
Si la couche du dessus ne sait toujours pas traiter, on remonte encore
d'un cran, est.
Au hasard :
int ma_fonction_qui_renvoie_une_erreur(paramètres d'entrée,
*paramètres de sortie).
C'est bien ce que je dis, des tricks à la con.
La signature de ta méthode ne se justifie que par des tricks pour
arriver à tes fins, en aucune manière par des préoccupations métier.
Arrête de ne pas regarder plus loin que le bout de ton nez. Je te
prends un exemple tout bête, un shell un peu spécial. S'il n'a plus
de mémoire disponible, il est de bon ton qu'il écrive sur stdout
"not enough memory" ou quelque chose du même genre en retournant une
invite (et au passage en libérant la mémoire qu'il était en train
d'utiliser pour essayer d'exécuter la dernière requête) et non en
segfaultant.
Euh, je ne vois pas la contradiction avec Java à ce niveau…
Même pire, Java est même totalement indiqué pour parvenir à tes fins :
int main(String[] args) {
try {
doBordel();
} catch (OutOfMemoryException e) {
System.err.println("Not enough memory");
} finally {
cleanDawa();
}
}
Quelque soit le bout de code qui manquera de mémoire et qui n'aura pas
été capable de se récupérer, mon programme fera ce que tu voulais =)
Le 18/06/2011 19:18, JKB a écrit :
Oui. Parce que c'est la seule façon d'avoir un truc fiable. Ton
exception est traitée en dehors de la fonction
Non, elle est traitée dans la fonction.
En tout cas si je sais faire une reprise sur erreur.
Sinon, je ne fais rien du tout et me contente de propager l'erreur,
jusqu'à ce que quelqu'un sache faire une reprise sur erreur.
pire, avec une
ribambelle et demi de fonctions appelées entre la chose qui a levé
ton exception et sa récupération.
Je ne suis pas toujours capable de prendre une décision sur comment
gérer mon erreur juste au moment où je détecte l'erreur.
Parfois, c'est seulement plusieurs couches au-dessus que je serais
capable de décider quoi faire.
Exemple tout con, une interface pour gérer des fichiers.
Localement je n'ai absolument aucune idée de comment faire une reprise
sur erreur si ma lecture échoue. Dois-je retenter ? Lire à un autre
emplacement ? Ne pas tenir compte de l'erreur ? Seule la couche du
dessus pourra et devra prendre cette décision.
Dans l'interface, toutes les méthodes vont donc lever potentiellement
une IOException, que la couche du dessus devra traiter suivant le cas
(AccessException = on peut sûrement retenter, InvalidFileException = le
chemin est mauvais, SocketClosedException = le réseau me permettant
d'accéder à mon fichier distant est mort…).
Si la couche du dessus ne sait toujours pas traiter, on remonte encore
d'un cran, est.
Au hasard :
int ma_fonction_qui_renvoie_une_erreur(paramètres d'entrée,
*paramètres de sortie).
C'est bien ce que je dis, des tricks à la con.
La signature de ta méthode ne se justifie que par des tricks pour
arriver à tes fins, en aucune manière par des préoccupations métier.
Arrête de ne pas regarder plus loin que le bout de ton nez. Je te
prends un exemple tout bête, un shell un peu spécial. S'il n'a plus
de mémoire disponible, il est de bon ton qu'il écrive sur stdout
"not enough memory" ou quelque chose du même genre en retournant une
invite (et au passage en libérant la mémoire qu'il était en train
d'utiliser pour essayer d'exécuter la dernière requête) et non en
segfaultant.
Euh, je ne vois pas la contradiction avec Java à ce niveau…
Même pire, Java est même totalement indiqué pour parvenir à tes fins :
int main(String[] args) {
try {
doBordel();
} catch (OutOfMemoryException e) {
System.err.println("Not enough memory");
} finally {
cleanDawa();
}
}
Quelque soit le bout de code qui manquera de mémoire et qui n'aura pas
été capable de se récupérer, mon programme fera ce que tu voulais =)
Le 18/06/2011 19:18, JKB a écrit :Oui. Parce que c'est la seule façon d'avoir un truc fiable. Ton
exception est traitée en dehors de la fonction
Non, elle est traitée dans la fonction.
En tout cas si je sais faire une reprise sur erreur.
Sinon, je ne fais rien du tout et me contente de propager l'erreur,
jusqu'à ce que quelqu'un sache faire une reprise sur erreur.
pire, avec une
ribambelle et demi de fonctions appelées entre la chose qui a levé
ton exception et sa récupération.
Je ne suis pas toujours capable de prendre une décision sur comment
gérer mon erreur juste au moment où je détecte l'erreur.
Parfois, c'est seulement plusieurs couches au-dessus que je serais
capable de décider quoi faire.
Exemple tout con, une interface pour gérer des fichiers.
Localement je n'ai absolument aucune idée de comment faire une reprise
sur erreur si ma lecture échoue. Dois-je retenter ? Lire à un autre
emplacement ? Ne pas tenir compte de l'erreur ? Seule la couche du
dessus pourra et devra prendre cette décision.
Dans l'interface, toutes les méthodes vont donc lever potentiellement
une IOException, que la couche du dessus devra traiter suivant le cas
(AccessException = on peut sûrement retenter, InvalidFileException = le
chemin est mauvais, SocketClosedException = le réseau me permettant
d'accéder à mon fichier distant est mort…).
Si la couche du dessus ne sait toujours pas traiter, on remonte encore
d'un cran, est.
Au hasard :
int ma_fonction_qui_renvoie_une_erreur(paramètres d'entrée,
*paramètres de sortie).
C'est bien ce que je dis, des tricks à la con.
La signature de ta méthode ne se justifie que par des tricks pour
arriver à tes fins, en aucune manière par des préoccupations métier.
Arrête de ne pas regarder plus loin que le bout de ton nez. Je te
prends un exemple tout bête, un shell un peu spécial. S'il n'a plus
de mémoire disponible, il est de bon ton qu'il écrive sur stdout
"not enough memory" ou quelque chose du même genre en retournant une
invite (et au passage en libérant la mémoire qu'il était en train
d'utiliser pour essayer d'exécuter la dernière requête) et non en
segfaultant.
Euh, je ne vois pas la contradiction avec Java à ce niveau…
Même pire, Java est même totalement indiqué pour parvenir à tes fins :
int main(String[] args) {
try {
doBordel();
} catch (OutOfMemoryException e) {
System.err.println("Not enough memory");
} finally {
cleanDawa();
}
}
Quelque soit le bout de code qui manquera de mémoire et qui n'aura pas
été capable de se récupérer, mon programme fera ce que tu voulais =)
Le 18/06/2011 19:19, JKB a écrit :Il y a pourtant des choses très bien en C.> ou du web en
> C/C⁺⁺ !
Idem.
Je n'ai jamais dis le contraire.
On peut même trouver de belles choses en brainfuck ou en whitespace…
Simplement que le coût d'intégration ne sera pas du tout le même entre
du Java et du C⁺⁺ pour ce genre de librairies.
Les services rendus par les librairies C/C⁺⁺ sont aussi extrèmement
moindres par rapport à ce qui est disponible en Java.
Le 18/06/2011 19:19, JKB a écrit :
Il y a pourtant des choses très bien en C.
> ou du web en
> C/C⁺⁺ !
Idem.
Je n'ai jamais dis le contraire.
On peut même trouver de belles choses en brainfuck ou en whitespace…
Simplement que le coût d'intégration ne sera pas du tout le même entre
du Java et du C⁺⁺ pour ce genre de librairies.
Les services rendus par les librairies C/C⁺⁺ sont aussi extrèmement
moindres par rapport à ce qui est disponible en Java.
Le 18/06/2011 19:19, JKB a écrit :Il y a pourtant des choses très bien en C.> ou du web en
> C/C⁺⁺ !
Idem.
Je n'ai jamais dis le contraire.
On peut même trouver de belles choses en brainfuck ou en whitespace…
Simplement que le coût d'intégration ne sera pas du tout le même entre
du Java et du C⁺⁺ pour ce genre de librairies.
Les services rendus par les librairies C/C⁺⁺ sont aussi extrèmement
moindres par rapport à ce qui est disponible en Java.
C'est vraiment du wishful thinking à l'état pur, ça.
C'est vraiment du wishful thinking à l'état pur, ça.
C'est vraiment du wishful thinking à l'état pur, ça.
Pas dans le monde Java.
Pas dans le monde Java.
Pas dans le monde Java.
entre un projet qui utilise systématiquement
trois bibliothèques élémentaires et un projet qui peut utiliser une
ribambelle de bibliothèques optionnelles, parfois de manière incompatible
et/ou redondante, parfois pas des appels indirects, etc. (je suis justement
en train de compiler un tel projet dans une fenêtre voisine), la gestion des
dépendances est radicalement différente.
entre un projet qui utilise systématiquement
trois bibliothèques élémentaires et un projet qui peut utiliser une
ribambelle de bibliothèques optionnelles, parfois de manière incompatible
et/ou redondante, parfois pas des appels indirects, etc. (je suis justement
en train de compiler un tel projet dans une fenêtre voisine), la gestion des
dépendances est radicalement différente.
entre un projet qui utilise systématiquement
trois bibliothèques élémentaires et un projet qui peut utiliser une
ribambelle de bibliothèques optionnelles, parfois de manière incompatible
et/ou redondante, parfois pas des appels indirects, etc. (je suis justement
en train de compiler un tel projet dans une fenêtre voisine), la gestion des
dépendances est radicalement différente.
Ah ? Et en quoi donc ?
Ah ? Et en quoi donc ?
Ah ? Et en quoi donc ?
Pas exactement. Mais si tu ne vois pas la différence, tant pis.
Pas exactement. Mais si tu ne vois pas la différence, tant pis.
Pas exactement. Mais si tu ne vois pas la différence, tant pis.
Tous les outils que tu veux ne parviendront pas à cacher cette réalité :
quand un programmeur ne comprend pas ce qu'il fait, il fait de la merde.
Tous les outils que tu veux ne parviendront pas à cacher cette réalité :
quand un programmeur ne comprend pas ce qu'il fait, il fait de la merde.
Tous les outils que tu veux ne parviendront pas à cacher cette réalité :
quand un programmeur ne comprend pas ce qu'il fait, il fait de la merde.