une fois que le flux est termine en lecture (boucle while : L 4) on
boucle sur le while (L 3), il se produit une erreur, car plus de flux
d'entree, (intercepte par le try) donc on reste bloque sur le while L3
!? et on attend soit une terminaison du flux soit une erreur de lecture
du flux?
5 : in.read(charBuffer,0,1); ici il faudrait exploiter le contenu, le stocker, si je comprends
6 : } 7 : } 8 : } catch(IO ....) { ...
une fois que le flux est termine en lecture (boucle while : L 4) Pas d'accord. Le marque un séparateur de champ, d'enregistrement, etc
mais pas la fermeture du flux.
on boucle sur le while (L 3), il se produit une erreur, car plus de flux d'entree, (intercepte par le try) donc on reste bloque sur le while L3 !? et on attend soit une terminaison du flux soit une erreur de lecture du flux?
pour moi boucle 4-6 : boucle sur les lignes boucle 3-7 : tant que flux non terminé - attention aux multiples in.read() car au passage on saute des chars (le premier de chaque enregistrement/ligne sauf erreur) mais c'est peut-être voulu - que fait on des chars lus ?
Ce code vient d'où ? Une idée de sa fonction et du contexte ? Pourquoi lire 1 par 1, sans bufferiser ?
Enfin bon, presque plus de questions que de réponses.
Manu wrote:
Bonjour,
bon je me lance. Qu'on n'hésite pas à compléter ou corriger.
5 : in.read(charBuffer,0,1);
ici il faudrait exploiter le contenu, le stocker, si je comprends
6 : }
7 : }
8 : }
catch(IO ....) {
...
une fois que le flux est termine en lecture (boucle while : L 4)
Pas d'accord. Le marque un séparateur de champ, d'enregistrement, etc
mais pas la fermeture du flux.
on
boucle sur le while (L 3), il se produit une erreur, car plus de flux
d'entree, (intercepte par le try) donc on reste bloque sur le while L3
!? et on attend soit une terminaison du flux soit une erreur de lecture
du flux?
pour moi boucle 4-6 : boucle sur les lignes
boucle 3-7 : tant que flux non terminé
- attention aux multiples in.read() car au passage on saute des chars
(le premier de chaque enregistrement/ligne sauf erreur) mais c'est
peut-être
voulu
- que fait on des chars lus ?
Ce code vient d'où ? Une idée de sa fonction et du contexte ? Pourquoi
lire 1 par 1, sans bufferiser ?
Enfin bon, presque plus de questions que de réponses.
5 : in.read(charBuffer,0,1); ici il faudrait exploiter le contenu, le stocker, si je comprends
6 : } 7 : } 8 : } catch(IO ....) { ...
une fois que le flux est termine en lecture (boucle while : L 4) Pas d'accord. Le marque un séparateur de champ, d'enregistrement, etc
mais pas la fermeture du flux.
on boucle sur le while (L 3), il se produit une erreur, car plus de flux d'entree, (intercepte par le try) donc on reste bloque sur le while L3 !? et on attend soit une terminaison du flux soit une erreur de lecture du flux?
pour moi boucle 4-6 : boucle sur les lignes boucle 3-7 : tant que flux non terminé - attention aux multiples in.read() car au passage on saute des chars (le premier de chaque enregistrement/ligne sauf erreur) mais c'est peut-être voulu - que fait on des chars lus ?
Ce code vient d'où ? Une idée de sa fonction et du contexte ? Pourquoi lire 1 par 1, sans bufferiser ?
Enfin bon, presque plus de questions que de réponses.
Manu
oui, en fait il s'agit de lire un flux, de le stocker puis de le dispatcher. j'ai alleger le code car inutile dans cet example : NB : in = new BufferedReader(new InputStreamReader(mySocket.getInputStream()));
En fait en ligne 5.1 on append charBuffer[0] dans une String puis en ligne 6.1 on dispatche le flux recut dans differents container. Bref qu'importe ces lignes. ce que j'ai constate avec .read() (ou .read( char , int , int); ) c'est que lorsque le flux envoye est entierement lu (dernier char == ' ') le in.read qui suit bug (intercepté par le try) et n'est donc pas traite, de ce fait "while(in.read(charBuffer,0,1) != -1) {" semble devenir "while() {" ou tout simplement attendre et ne pas traiter le contenu des accolades du while. Et des qu'un flux arrive le while sort du sommeil et execute sa condition et le contenu de ses accolades. Tout ceci me semble encore tres abstrait...
si quelqu'un a une explication plus concrete du comportement de cette class...
manu
Manu wrote:
Bonjour, bon je me lance. Qu'on n'hésite pas à compléter ou corriger.
ici il faudrait exploiter le contenu, le stocker, si je comprends
6 : } 7 : } 8 : } catch(IO ....) { ...
une fois que le flux est termine en lecture (boucle while : L 4)
Pas d'accord. Le marque un séparateur de champ, d'enregistrement, etc mais pas la fermeture du flux.
on boucle sur le while (L 3), il se produit une erreur, car plus de flux d'entree, (intercepte par le try) donc on reste bloque sur le while L3 !? et on attend soit une terminaison du flux soit une erreur de lecture du flux?
pour moi boucle 4-6 : boucle sur les lignes boucle 3-7 : tant que flux non terminé - attention aux multiples in.read() car au passage on saute des chars (le premier de chaque enregistrement/ligne sauf erreur) mais c'est peut-être voulu - que fait on des chars lus ?
Ce code vient d'où ? Une idée de sa fonction et du contexte ? Pourquoi lire 1 par 1, sans bufferiser ?
Enfin bon, presque plus de questions que de réponses.
oui, en fait il s'agit de lire un flux, de le stocker puis de le
dispatcher. j'ai alleger le code car inutile dans cet example :
NB : in = new BufferedReader(new
InputStreamReader(mySocket.getInputStream()));
En fait en ligne 5.1 on append charBuffer[0] dans une String puis en
ligne 6.1 on dispatche le flux recut dans differents container. Bref
qu'importe ces lignes.
ce que j'ai constate avec .read() (ou .read( char , int , int); ) c'est
que lorsque le flux envoye est entierement lu (dernier char == ' ') le
in.read qui suit bug (intercepté par le try) et n'est donc pas traite,
de ce fait "while(in.read(charBuffer,0,1) != -1) {" semble devenir
"while() {" ou tout simplement attendre et ne pas traiter le contenu des
accolades du while. Et des qu'un flux arrive le while sort du sommeil et
execute sa condition et le contenu de ses accolades. Tout ceci me semble
encore tres abstrait...
si quelqu'un a une explication plus concrete du comportement de cette
class...
manu
Manu wrote:
Bonjour,
bon je me lance. Qu'on n'hésite pas à compléter ou corriger.
ici il faudrait exploiter le contenu, le stocker, si je comprends
6 : }
7 : }
8 : }
catch(IO ....) {
...
une fois que le flux est termine en lecture (boucle while : L 4)
Pas d'accord. Le marque un séparateur de champ, d'enregistrement, etc
mais pas la fermeture du flux.
on boucle sur le while (L 3), il se produit une erreur, car plus de
flux d'entree, (intercepte par le try) donc on reste bloque sur le
while L3 !? et on attend soit une terminaison du flux soit une erreur
de lecture du flux?
pour moi boucle 4-6 : boucle sur les lignes
boucle 3-7 : tant que flux non terminé
- attention aux multiples in.read() car au passage on saute des chars
(le premier de chaque enregistrement/ligne sauf erreur) mais c'est
peut-être
voulu
- que fait on des chars lus ?
Ce code vient d'où ? Une idée de sa fonction et du contexte ? Pourquoi
lire 1 par 1, sans bufferiser ?
Enfin bon, presque plus de questions que de réponses.
oui, en fait il s'agit de lire un flux, de le stocker puis de le dispatcher. j'ai alleger le code car inutile dans cet example : NB : in = new BufferedReader(new InputStreamReader(mySocket.getInputStream()));
En fait en ligne 5.1 on append charBuffer[0] dans une String puis en ligne 6.1 on dispatche le flux recut dans differents container. Bref qu'importe ces lignes. ce que j'ai constate avec .read() (ou .read( char , int , int); ) c'est que lorsque le flux envoye est entierement lu (dernier char == ' ') le in.read qui suit bug (intercepté par le try) et n'est donc pas traite, de ce fait "while(in.read(charBuffer,0,1) != -1) {" semble devenir "while() {" ou tout simplement attendre et ne pas traiter le contenu des accolades du while. Et des qu'un flux arrive le while sort du sommeil et execute sa condition et le contenu de ses accolades. Tout ceci me semble encore tres abstrait...
si quelqu'un a une explication plus concrete du comportement de cette class...
manu
Manu wrote:
Bonjour, bon je me lance. Qu'on n'hésite pas à compléter ou corriger.
ici il faudrait exploiter le contenu, le stocker, si je comprends
6 : } 7 : } 8 : } catch(IO ....) { ...
une fois que le flux est termine en lecture (boucle while : L 4)
Pas d'accord. Le marque un séparateur de champ, d'enregistrement, etc mais pas la fermeture du flux.
on boucle sur le while (L 3), il se produit une erreur, car plus de flux d'entree, (intercepte par le try) donc on reste bloque sur le while L3 !? et on attend soit une terminaison du flux soit une erreur de lecture du flux?
pour moi boucle 4-6 : boucle sur les lignes boucle 3-7 : tant que flux non terminé - attention aux multiples in.read() car au passage on saute des chars (le premier de chaque enregistrement/ligne sauf erreur) mais c'est peut-être voulu - que fait on des chars lus ?
Ce code vient d'où ? Une idée de sa fonction et du contexte ? Pourquoi lire 1 par 1, sans bufferiser ?
Enfin bon, presque plus de questions que de réponses.