Arrêter le parser SAX

Cheyenne wrote:

En désespoir de cause, il y aurait bien la possibilité de balancer une
exception, mais c'est goret.

Merci d'avance pour vos réponses.

HTH

D'après ce que j'ai lu, la seule solution serait donc de lancer une
exception... j'avoue que ce n'est très propre pour stopper un parsing
mais bon, je vais voir si ça vaut vraiment le coup d'un point de vue
performances. J'y avais d'ailleurs réfléchi mais je pensais qu'il y
avait une manière plus élégante de le faire.

Attention, contrairement à ce que raconte notre ami inconnu, jdom n'est
pas plus facile ni mieux que sax. Le dom est une toute autre approche du
parsing xml. Le choix du sax ou du dom dépend avant tout des besoins
(mémoire, rapidité ...)

Petite précision, JDOM est juste un nom générique, a l'intérieur il y
a un SAXBuilder qui parse en SAX.
autant pour moi !

SK wrote:

Cheyenne wrote:

En désespoir de cause, il y aurait bien la possibilité de balancer une
exception, mais c'est goret.

Merci d'avance pour vos réponses.

HTH

D'après ce que j'ai lu, la seule solution serait donc de lancer une
exception... j'avoue que ce n'est très propre pour stopper un parsing
mais bon, je vais voir si ça vaut vraiment le coup d'un point de vue
performances. J'y avais d'ailleurs réfléchi mais je pensais qu'il y
avait une manière plus élégante de le faire.

Je suis d'accord que lancer une exception n'est pas propre - une exception
par definition est a utiliser quand il y a une condition ...
exceptionelle, ce qui n'est pas le cas ici.
J'ai une autre solution a ce probleme qui ne fait pas appel a une
exception, mais elle est plutot compliquee, mais n'apporte rien de plus
ici, si ce n'est de l'elegance.

dans le message
"Marc Petit-Huguenin" <marc@petit-huguenin.org> a écrit dans le message de
news:rRptc.7594$n_6.2702@attbi_s53...

SK wrote:

Cheyenne wrote:

En désespoir de cause, il y aurait bien la possibilité de balancer
une

exception, mais c'est goret.

Merci d'avance pour vos réponses.

HTH

D'après ce que j'ai lu, la seule solution serait donc de lancer une
exception... j'avoue que ce n'est très propre pour stopper un parsing
mais bon, je vais voir si ça vaut vraiment le coup d'un point de vue
performances. J'y avais d'ailleurs réfléchi mais je pensais qu'il y
avait une manière plus élégante de le faire.

Je suis d'accord que lancer une exception n'est pas propre - une exception
par definition est a utiliser quand il y a une condition ...
exceptionelle, ce qui n'est pas le cas ici.

ah parce que arrêter le parsing ce n'est pas une condition exceptionnelle
????

Personnellement, je trouve cela très élégant.

Tu peux pour cela utiliser une class nommée StopParsingException extends
org.xml.sax.SAXException

puis dans ton ContentHandler
quand tu veux arrêter (dans un endElement j'imagine) tu lances
un throw new StopParsingException ()

Grâce à cela dans ta class ayant lancé le parsing
try {
tout ce qu'il faut pour le parsing
ton xmlreader
ton setcontenthandler
} catch (StopParsingException e) {
la pas de problème
} catch (SAXException e) {
là problème
}

J'ai une autre solution a ce probleme qui ne fait pas appel a une
exception, mais elle est plutot compliquee, mais n'apporte rien de plus
ici, si ce n'est de l'elegance.

cilovie wrote:

dans le message
"Marc Petit-Huguenin" <marc@petit-huguenin.org> a écrit dans le message de
news:rRptc.7594$n_6.2702@attbi_s53...

SK wrote:

Cheyenne wrote:

En désespoir de cause, il y aurait bien la possibilité de balancer

une

exception, mais c'est goret.

Merci d'avance pour vos réponses.

HTH

D'après ce que j'ai lu, la seule solution serait donc de lancer une
exception... j'avoue que ce n'est très propre pour stopper un parsing
mais bon, je vais voir si ça vaut vraiment le coup d'un point de vue
performances. J'y avais d'ailleurs réfléchi mais je pensais qu'il y
avait une manière plus élégante de le faire.

Je suis d'accord que lancer une exception n'est pas propre - une exception
par definition est a utiliser quand il y a une condition ...
exceptionelle, ce qui n'est pas le cas ici.

ah parce que arrêter le parsing ce n'est pas une condition exceptionnelle
????

Personnellement, je trouve cela très élégant.

Je ne trouve pas. Si tu regardes dans les posts precedents, c'est aussi ce
que j'ai propose comme moyen pratique d'arreter le parsing. C'est pratique,
mais c'est pas elegant:

Qu'est-ce qui ce passe si on a besoin de gerer les endElements suivants,
voir le endDocument? Les methodes ne sront jamais appellees dans ce cas la.
Bien sur c'est possible de rajouter le traitement juste avant de lancer
l'exception, mais ca devient tout sauf elegant a ce moment la. Le premier
indice de l'elegance d'un design c'est sa capacite a continuer d'etre
valide quand les besoins evoluent. Le design ici ne passe pas ce premier
test...

Tu peux pour cela utiliser une class nommée StopParsingException extends
org.xml.sax.SAXException

puis dans ton ContentHandler
quand tu veux arrêter (dans un endElement j'imagine) tu lances
un throw new StopParsingException ()

Grâce à cela dans ta class ayant lancé le parsing
try {
tout ce qu'il faut pour le parsing
ton xmlreader
ton setcontenthandler
} catch (StopParsingException e) {
la pas de problème
} catch (SAXException e) {
là problème
}

J'ai une autre solution a ce probleme qui ne fait pas appel a une
exception, mais elle est plutot compliquee, mais n'apporte rien de plus
ici, si ce n'est de l'elegance.

"Marc Petit-Huguenin" <marc@petit-huguenin.org> a écrit dans le message de
news:r_rtc.652$pt3.529@attbi_s03...

cilovie wrote:

dans le message
"Marc Petit-Huguenin" <marc@petit-huguenin.org> a écrit dans le message
de

news:rRptc.7594$n_6.2702@attbi_s53...

SK wrote:

Cheyenne wrote:

En désespoir de cause, il y aurait bien la possibilité de balancer

une

exception, mais c'est goret.

Merci d'avance pour vos réponses.

HTH

D'après ce que j'ai lu, la seule solution serait donc de lancer une
exception... j'avoue que ce n'est très propre pour stopper un parsing
mais bon, je vais voir si ça vaut vraiment le coup d'un point de vue
performances. J'y avais d'ailleurs réfléchi mais je pensais qu'il y
avait une manière plus élégante de le faire.

Je suis d'accord que lancer une exception n'est pas propre - une
exception

par definition est a utiliser quand il y a une condition ...
exceptionelle, ce qui n'est pas le cas ici.

ah parce que arrêter le parsing ce n'est pas une condition
exceptionnelle

????

Personnellement, je trouve cela très élégant.

Je ne trouve pas. Si tu regardes dans les posts precedents, c'est aussi ce
que j'ai propose comme moyen pratique d'arreter le parsing. C'est
pratique,

mais c'est pas elegant:

Qu'est-ce qui ce passe si on a besoin de gerer les endElements suivants,
voir le endDocument? Les methodes ne sront jamais appellees dans ce cas
la.

Bien sur c'est possible de rajouter le traitement juste avant de lancer
l'exception, mais ca devient tout sauf elegant a ce moment la. Le premier
indice de l'elegance d'un design c'est sa capacite a continuer d'etre
valide quand les besoins evoluent. Le design ici ne passe pas ce premier
test...

Je répondais simplement au besoin exprimé dans premier post qui était je
cite :

Bonjour,

J'utilise actuellement un parser SAX pour lire un fichier XML.
Existerait-il un moyen de le stopper (lors de la rencontre d'une fin de
balise précise, par exemple) et donc l'empêcher de parcourir tout le
document (qui est assez gros) ?
C'est aussi parce que je n'ai besoin que d'en récupérer une sous-partie.

Merci d'avance pour vos réponses.


Donc si je lis le besoin, il y a bien écrit: et donc l'empêcher de parcourir
tout le document (qui est assez gros)

Parce que : if (e.getException() instanceof RuntimeException) c'est élégant
????

surtout que si pour une raison quelconque il y a une vrai RuntimeException
qui est levée (une NullPointerException ou n'importe quelle autre). Là tu
vas vraiment rencontrer un bug

Tu peux pour cela utiliser une class nommée StopParsingException extends
org.xml.sax.SAXException

puis dans ton ContentHandler
quand tu veux arrêter (dans un endElement j'imagine) tu lances
un throw new StopParsingException ()

Grâce à cela dans ta class ayant lancé le parsing
try {
tout ce qu'il faut pour le parsing
ton xmlreader
ton setcontenthandler
} catch (StopParsingException e) {
la pas de problème
} catch (SAXException e) {
là problème
}

J'ai une autre solution a ce probleme qui ne fait pas appel a une
exception, mais elle est plutot compliquee, mais n'apporte rien de plus
ici, si ce n'est de l'elegance.

cilovie wrote:

"Marc Petit-Huguenin" <marc@petit-huguenin.org> a écrit dans le message de
news:r_rtc.652$pt3.529@attbi_s03...

cilovie wrote:

[snip]

????

Personnellement, je trouve cela très élégant.

Je ne trouve pas. Si tu regardes dans les posts precedents, c'est aussi ce
que j'ai propose comme moyen pratique d'arreter le parsing. C'est

pratique,

mais c'est pas elegant:

Qu'est-ce qui ce passe si on a besoin de gerer les endElements suivants,
voir le endDocument? Les methodes ne sront jamais appellees dans ce cas

la.

Bien sur c'est possible de rajouter le traitement juste avant de lancer
l'exception, mais ca devient tout sauf elegant a ce moment la. Le premier
indice de l'elegance d'un design c'est sa capacite a continuer d'etre
valide quand les besoins evoluent. Le design ici ne passe pas ce premier
test...

Je répondais simplement au besoin exprimé dans premier post qui était je
cite :

Bonjour,

J'utilise actuellement un parser SAX pour lire un fichier XML.
Existerait-il un moyen de le stopper (lors de la rencontre d'une fin de
balise précise, par exemple) et donc l'empêcher de parcourir tout le
document (qui est assez gros) ?
C'est aussi parce que je n'ai besoin que d'en récupérer une sous-partie.

Merci d'avance pour vos réponses.


Donc si je lis le besoin, il y a bien écrit: et donc l'empêcher de parcourir
tout le document (qui est assez gros)

Parce que : if (e.getException() instanceof RuntimeException) c'est élégant
????

C'est justement ce que je dis - c'est pas elegant. Mais c'est le lancement
de l'exception lui-meme qui n'est pas elegant. C'est toute la difference
entre ca:

int[] array = ...
int total = 0;
for (int i = 0; i < array.length; i++) {
total += array[i];
}

et ca:

int[] array = ...
int total = 0;
try {
int i = 0;
while (true) {
total += array[i++];
}
}
catch (ArrayIndexOutOfBoundsException ) {}

surtout que si pour une raison quelconque il y a une vrai RuntimeException
qui est levée (une NullPointerException ou n'importe quelle autre). Là tu
vas vraiment rencontrer un bug

Oui, c'etait pour ne pas compliquer l'exemple - c'est evident qu'il faut
creer une nouvelle exception.

Tu peux pour cela utiliser une class nommée StopParsingException extends
org.xml.sax.SAXException

puis dans ton ContentHandler
quand tu veux arrêter (dans un endElement j'imagine) tu lances
un throw new StopParsingException ()

Grâce à cela dans ta class ayant lancé le parsing
try {
tout ce qu'il faut pour le parsing
ton xmlreader
ton setcontenthandler
} catch (StopParsingException e) {
la pas de problème
} catch (SAXException e) {
là problème
}

J'ai une autre solution a ce probleme qui ne fait pas appel a une
exception, mais elle est plutot compliquee, mais n'apporte rien de plus
ici, si ce n'est de l'elegance.

"Marc Petit-Huguenin" <marc@petit-huguenin.org> a écrit dans le message de
news:OSstc.8319$n_6.216@attbi_s53...

cilovie wrote:

"Marc Petit-Huguenin" <marc@petit-huguenin.org> a écrit dans le message
de

news:r_rtc.652$pt3.529@attbi_s03...

cilovie wrote:

[snip]

????

Personnellement, je trouve cela très élégant.

Je ne trouve pas. Si tu regardes dans les posts precedents, c'est aussi
ce

que j'ai propose comme moyen pratique d'arreter le parsing. C'est

pratique,

mais c'est pas elegant:

Qu'est-ce qui ce passe si on a besoin de gerer les endElements suivants,
voir le endDocument? Les methodes ne sront jamais appellees dans ce cas

la.

Bien sur c'est possible de rajouter le traitement juste avant de lancer
l'exception, mais ca devient tout sauf elegant a ce moment la. Le
premier

indice de l'elegance d'un design c'est sa capacite a continuer d'etre
valide quand les besoins evoluent. Le design ici ne passe pas ce premier
test...

Je répondais simplement au besoin exprimé dans premier post qui était je
cite :

Bonjour,

J'utilise actuellement un parser SAX pour lire un fichier XML.
Existerait-il un moyen de le stopper (lors de la rencontre d'une fin de
balise précise, par exemple) et donc l'empêcher de parcourir tout le
document (qui est assez gros) ?
C'est aussi parce que je n'ai besoin que d'en récupérer une sous-partie.

Merci d'avance pour vos réponses.


Donc si je lis le besoin, il y a bien écrit: et donc l'empêcher de
parcourir

tout le document (qui est assez gros)

Parce que : if (e.getException() instanceof RuntimeException) c'est
élégant

????

C'est justement ce que je dis - c'est pas elegant. Mais c'est le lancement
de l'exception lui-meme qui n'est pas elegant. C'est toute la difference
entre ca:

int[] array = ...
int total = 0;
for (int i = 0; i < array.length; i++) {
total += array[i];
}

et ca:

int[] array = ...
int total = 0;
try {
int i = 0;
while (true) {
total += array[i++];
}
}
catch (ArrayIndexOutOfBoundsException ) {}

Oui mais cela pour des raisons de performance cela se discute !!

Tiré de java performance tuning


Use the runtime to do error checking for you.
If errors are expected to be rare, don't waste time doing an
application-level check where the runtime is already doing a check for you,
eg ArrayIndexOutOfBoundsException.
Since this check is going to be done whether you like it or not, you could
use this to break loops rather than an explicit check of some other loop
conditional. For
example, instead of this:

public class test {
public static void main(String[] args) {
int array[] = new int[1000000];

for (int i=0; i<array.length; i++) {
array[i] = i;
}
}
}

you could do this:

public class test {
public static void main(String[] args) {
int array[] = new int[1000000];

try {
for (int i=0; ; i++) {
array[i] = i;
}
}
catch(ArrayIndexOutOfBoundsException aioobe) {}
}
}

The first one takes about 1.5 seconds to run on my P233, the second takes
about 1.1 seconds. But it is even faster to just set the array bounds to a
local (stack) variable, so this is not a practical example.

surtout que si pour une raison quelconque il y a une vrai
RuntimeException

qui est levée (une NullPointerException ou n'importe quelle autre). Là
tu

vas vraiment rencontrer un bug

Oui, c'etait pour ne pas compliquer l'exemple - c'est evident qu'il faut
creer une nouvelle exception.

Tu peux pour cela utiliser une class nommée StopParsingException
extends

org.xml.sax.SAXException

puis dans ton ContentHandler
quand tu veux arrêter (dans un endElement j'imagine) tu lances
un throw new StopParsingException ()

Grâce à cela dans ta class ayant lancé le parsing
try {
tout ce qu'il faut pour le parsing
ton xmlreader
ton setcontenthandler
} catch (StopParsingException e) {
la pas de problème
} catch (SAXException e) {
là problème
}

J'ai une autre solution a ce probleme qui ne fait pas appel a une
exception, mais elle est plutot compliquee, mais n'apporte rien de
plus

ici, si ce n'est de l'elegance.