Oui tu as raison, mais au moment où j'ai codé cette classe, je voulais voir ce que cela donnait de gérer les exceptions interception comprise dans la classe.
En fait, ça ne sert à rien si ce n'est à perdre des ressources pour rien...faudra que je recode ça.
Alakhnor => l'utilisation de ces classes passent nécessairement par une revisite de ton code. Il faut le voir autrement : la boucle est gérée par du javascript, c'est tout.
Poutr php4, tu dois pouvoir réécrire la classe php...à priori. Rien de vital ne tire partie des spécificités PHP5.
Etrange, je ne l'aurais pas codé comme ca cette classe.
Enfin si, mais au niveau des try{}catch() non.
J'aurais dégagé les try{}catch() des méthodes pour commencer.
Théoriquement, le try{}catch() se fait lors d'un appel de méthode et pas dans la méthode elle même. Sauf si c'est pour appeler une méthodes privée/protégée.
Ex :
# public function __set ($sType, $sVal) {
# try {
# if (!array_key_exists ($sType, $this -> aProps)) {
# throw new Exception ($sType.' is not a valid property');
# }
# } catch (Exception $e) {
# echo $e -> getMessage ();
# }
Ce que j'aurais fait :
public function __set($var, $val) {
if ( !array_key_exists($var, $this -> aProps) )
throw new GetSetException($var, 'set');
// suite...
}
Et quand tu appèles ta classe de l'extérieur :
try {
$maclasse = new noTimeOut;
$maclasse->timeout = 360;
// etc..
} catch ( GetSetException $gs ) {
die ( $gs->getMessage() );
} catch ( Exception $e ) {
die ( $e->getMessage() );
}
Par contre (voila la suite ^^) :
#public function flushMe ($aWork = null) {
# try {
# switch ($this -> aProps['TYPE']) {
# case 'DB':
# if (false === self::isNull ($this -> aProps['DB'], $this -> aProps['HOST'], $this -> aProps['LOGIN'], $this -> aProps['PWD'], $this -> aProps['QUERY'], $this -> aProps['DBSERVER'], $this -> aProps['START'], $this -> aProps['STEP'])) {
# throw new Exception ('DB properties have not been fully defined');
# }
# $mTmp = $this -> getDB ();
# break;
Voila comment je l'aurais joué. J'aurais étendu la classe d'exception pour chaque cas :)
Autrement, ton try{}catch() ne sert pas à grand chose dans une classe :)
J'aimerais pouvoir utiliser ces classes. Malheureusement, je me heurte à 2 problèmes:
- je dois développer en php4
- mon programme est une boucle effectuant un certains nombre de traitements incluant des requêtes vers FlickR calculées par le reste. Je ne vois pas trop comment déporter des traitements et les traiter dans la classe php.
yess !
merci pour tes explications :)
je vais tester ça de ce pas ... puis allez j'te fais un petit vote pour tous les efforts que tu fais pour nous ;)
merki
@++
Caviar => ton serveur est configuré en short_open_tag à On. Et c'est maaal ;-)
Donc, soit tu le mets en short_open_tag à Off, histoire qu'il ne prenne pas le <? de la l'en tête XML pour du php, soit tu fais un echo :
echo '<?xml version="1.0" encoding="iso-8859-1"?>';
Pour les autres parse error, forcément...s'il commence à interpréter ça comme du php, il continue jusqu'à ce qu'il rencontre un tag de fermeture...donc, tout le html est interprété comme du PHP.
euh ...saluté
le système à l'air très intéréssant cependant en testant en local avec php 5.1.2 j'ai cette erreur
Parse error: parse error in c:\no_time_out_package\obuffer\index.php on line 13
la ligne en question étant
<?xml version="1.0" encoding="iso-8859-1"?>
effectivement je comprends bien que le serveur interprète ça en php alors que ça n'en est pas.
même si j'enlève cette ligne j'ai plein de parse error :(
@++
Je viens de mettre à jour la source.
Je n'ai pas fini encore, mais déjà, une addition importante : le package gère maintenant des piles de processus. Ce qui veut dire que l'on peut lancer plusieurs traitements en asynchrone : lire 2 fichiers à la fois par exemple.
index6.php a aussi été ajouté et montre justement ce fonctionnement.
La façon d'instancier l'objet a été modifié aussi, voir le readme.txt et les différents fichiers.
A ok, je comprens mieux maintenant,
Script intéressant, et bien élaboré,
bonne explication et suivie de la source,
ce qui est assez rare....
Ma note : 10
La fonction set_time_limit () ne fonctionne que si l'hébergeur laisse l'accès à cette fonction. Ce qui est très rarement le cas en mutualisé. Et pour cause...
Evidemment, on peut aussi modifier le php.ini. Idem, il faut y avoir accès.
Il y aussi le safe mode, s'il est activé, et qu'on veut le garder (ahem), on ne peut pas modifier comme ça ces valeurs.
Ce script est fait pour ce genre de situations. Mais il a aussi un autre avantage : avec un set_time_limit (0), ta page restera vierge jusqu'à ce que le traitement soit terminé. Ce qui peut prendre 1mn, 2mn, 10mn...etc. Sans rien. Ce script, lui, affiche en continue les données qu'il récupère. La page est "vivante", elle bouge, elle ne laisse pas l'utilisateur devant une page vide.
"Ps : c'est pour PHP5, les exceptions, hein."
>> J' ai vu ^^ merci ;-)
Merci pour ces explications ;-)
Dernier petit truc tu as omis de mettre une vérification en JavaScript ( enfin plustot en Ajax ^^ ) :
Tu ne vérif pas si la page a été trouvée :S c' est pas obligé mais c' est mieux :
if(oXmlhttp.readyState 4 && oXmlhttp.status 404){// Erreur 404 ! Fichier introuvable !
document.getElementById(MSG).innerHTML = '
Le fichier ' + SCRIPT + ' n\' existe pas !
';
return false;
}
Sinon, je me rends compte que pour bien utiliser ce package, il faut comprendre ce qu'il fait...j'incluerai un tuto dans le package un de ces jours.
Mais je vais donner un exemple :
sans utiliser la classe PHP, qui ne servira à rien dans ce cas. On peut utiliser la classe JS, elle facilitera les choses.
Il suffit d'utiliser sa méthode getDefault (donc, type = DEFAULT).
On met un STEP de 100 par exemple, un START à 0, et pas de limite (dans ce cas, virer le if (j < LIMIT) et toujours rappeler récursivement la méthode xmlhttp), ou une très grande limite, genre 1 milliard. Dans le fichier de traitement PHP, on récupère START, et STEP. Et on fait un truc du genre : for ($i = START; $i < START + STEP; $i ++) et on affiche $i. (je n'ai pas utiliser les bonnes variables hein, ce sera $_POST['iStart'] par exemple, si on reste dans le cadre de mon package). On met dans ce fichier, et même le fichier d'appel pour être convaincu, un set_time_limit (5) par exemple.
Tu verras que PHP affichera les chiffres, sans sourciller. Il pourra ainsi tourner indéfiniment, jusqu'à arriver à LIMIT s'il y en a une, et affichera : 0, 1, 2...500...10000...99999999, 999999999999999 etc... durant des jours et des jours si tu le veux.
Essaye de faire ça sans mon package, ou du moins, sans ce qu'il montre (avec un time_limit évidemment hein), tu auras du mal.
Ce package peut aussi permettre d'éviter le dépassement de la mémoire allouée à PHP dans certain cas. Une énorme requête par exemple, qui va chercher des tonnes d'enregistrements, peut planter à ce niveau là, avant le timeout. Ben là c'est pareil, vu que je vais récupérer mes enregistrements en plusieurs passes, la mémoire allouée ne sera pas dépasser (si on calcule bien hein).
Bien sûr, ce n'est pas valable pour, par exemple, le redimensionnement d'une image énorme! On ne peut - à priori - pas faire ça en plusieurs passes. Donc...niet.
Ben évidemment que je ruse. Le timeout est celui de PHP : le max_execution_time. Il est fixé à 30, 60 etc secondes. Si on a pas la main sur le serveur, on ne peut généralement pas le changer.
Mais Ajax, c'est du js, donc ce n'est pas soumis au timeout. Mon package utilise Ajax pour effectuer un traitement lourd en plusieurs fois, en appelant un nombre de fois le traitement serveur, nbre de fois défini par le STEP et LIMIT, STEP se chargeant aussi d'incrémenter le traitement: par exemple, j'ai un fichier de 10000 lignes, je veux le lire en entier mais avec PHP ça prend trop de temps. Donc j'utilise ce package pour lire, par exemple, le fichier 100 lignes par 100 lignes. Ajax me l'affiche 100 lignes par 100 lignes (en gardant les lignes précédentes évidemment) : j'ai un affichage séquentiel, qui dure ce qu'il dure, mais qui n'est jamais arrêté avant la fin de la lecture complète.
Même principe pour n'importe quel autre traitement : je veux envoyer 50000 emails ? Pas de problème. Lire une table contenant 1000000 d'entrées ? No problemo... ;-)
Ma théorie est bonne. Il suffit simplement de bien calculer son coup et de ne pas faire faire plus de traitements au serveur qu'il n'en faut pour rester dans le temps limite.
Et elle est bonne parce que : xmlhttp est un objet javascript, donc exécuté côté client. On appelle grâce à lui un traitement côté serveur. A ce moment, le décompte du temps commence. Le traitement s'effectue. S'il dure trop longtemps, boum, timeout. D'où le STEP que j'ai mis dans mes classes. Une fois le traitement effectué, le serveur balance le résultat au client, et évidemment, vu qu'on quitte le serveur, le décompte s'arrête et le temps imparti revient à 0. Là, ma classe vérifie si on a fini (LIMIT), sinon, elle rebalance un traitement, en incrémentant grâce au STEP, au serveur. Le décompte recommence, etc.
Soit tu as mal utilisé ma classe, soit ton STEP est trop gros.
Chez moi ça marche parfaitement. Sauf dans un cas : si on fait une connerie dans l'utilisation qui provoque une erreur dans la classe PHP par exemple (et encore, normalement, plus maintenant, vu que j'intercepte tout).
Quant à avoir une idée, non, pas son le code utilisé.
Désoler de casser l' embiance :S mais ta théorie comme quoi ajax empêcherai le timeout est fausse :S
Ou alors mauvaise manipulation du code de ma part !?
Ouais, tien, je pensais que c'était true par défaut moi...bizarre. D'autant plus que ça tourne chez moi.
Bon enfin je vais mettre true aussi, ça fera pas de mal!
Salut,
Nan ça marche pas non plus :S
Mais j' ai trouvé d' où venais le problème ;-)
oXmlhttp.open('POST', SCRIPT);
Il manque le dernier paramètre ^^ et or quand on ne met rien il a pour valeur false ^^
Dès que j' ai mit oXmlhttp.open('POST', SCRIPT, true);
ça a marché nikel ;-)
"PHP version 4.3.3, et ça marche sous IE...?
T'es sûr de ta version de PHP hein ? Parce que la classe noTimeOut PHP est écrite en PHP5."
>> Enfin quand je dis que ça marche ajax marche ^^
Il est évidant que la class php ne puisse marcher.
Mais ce que je voulais voir c' etait ta class en javascript donc peu importe la version de php ^^
Avec IE il m' envoie toutes les erreurs qui sont faites avec php, alors qu' avec FF rien :'(
"Bon enfin, quelle est l'erreur JS sous firefox ?"
>> Il n' y a aucune erreur !!!
C' est trop zarb :S
"Essaye en virant le parent devant document...mais je ne suis pas convaincu.
essaye aussi en gardant parent.blabla, mais à la place du appendChild (), tu mets un bon vieux non standard
parent.document.getElementById(TARGET).innerHTML += oXmlhttp.responseText"
>> J' y ai déjà pensé ^^
J' ai essayé:
parent.document.getElementById(TARGET).innerHTML = oXmlhttp.responseText;
Immortal => essaye aussi en gardant parent.blabla, mais à la place du appendChild (), tu mets un bon vieux non standard
parent.document.getElementById(TARGET).innerHTML += oXmlhttp.responseText
Mais si ça vient vraiment du TARGET, ben y a un truc qui ne colle pas. S'il est bien défini dans ta page appelant, et que la classe js est bien incluse via <script.../>, elle doit trouver l'élément dans le document parent.
Jean84 => là j'utilise la classe Exception standard, je n'ai pas défini la mienne. Je le ferai peut-être, pour le fun, et mieux séparer les choses. La doc officielle est pratique, mais manque d'infos à ce sujet, c'est vrai.
Cet article sur les blogs dév de Zend est pas mal (mais en anglais hein, je précise pour les réfractaires):
http://devzone.zend.com/node/view/id/666
"PHP version 4.3.3, et ça marche sous IE...?
T'es sûr de ta version de PHP hein ? Parce que la classe noTimeOut PHP est écrite en PHP5.
- Mdr, fallait oser ^^, surtout que le titre est plus qu'evocateur : [PHP5] NOTIMEOUT PACKAGE
- J'ai jamais compris comment on pouvait definir sa propre classe d'exeptions. J'ai voulu l'utiliser avec mes classes en C++ mais a chaque fois je me bornais a n'utiliser qu'un seul catch(..) afin de tout recuperer, car je pigeais a peu pres.. que dalle ! lol
Comment sa fonctionne en php5 ? T'as un tuto ou un truc dans le genre ??
PHP version 4.3.3, et ça marche sous IE...?
T'es sûr de ta version de PHP hein ? Parce que la classe noTimeOut PHP est écrite en PHP5.
Bon enfin, quelle est l'erreur JS sous firefox ?
Essaye en virant le parent devant document...mais je ne suis pas convaincu.
Et puis c'est bizarre que sur mon firefox ça marche, si c'était un problème client.
Et côté serveur, ça devrait ne PAS DU TOUT marcher, avec PHP4.
"Ouais mais 1 try appelle 1 catch. Et je voulais, ici, 1 catch par erreur possible : connexion échouée, sélection de la db échouée, etc..."
la succetion de if te sert justement à preparer le catch final...
Mais c'est vrai que si il y a une hierarchie dans les etapes, on est obliger de faire comme tu a fait, a ok, ... Et ouai si on veut afficher que l'erreur primaire en effet.
C'est peu compliqué tout de meme. :p
Je ne l'ai pas testé sous...IE. Je ne l'ai testé que sous Firefox.
Au passage, je n'ai pas fini l'implémentation du message, justement. Vais m'y atteler.
Montre le code de ton index (ou dis moi lequel tu utilises si tu n'as rien modifié), idem pour le script.
Salut,
Chez moi j' ai un bug quand je le test avec firefox !
ça met Attente :@
Alors qu' avec IE aucun bug :S
J' ai fait quelque essaie et ça viendrait de la ligne 118 :
parent.document.getElementById (TARGET).firstChild.appendData (oXmlhttp.responseText);
oXmlhttp.responseText a des données correctes mais l' affectation de ces données à l' id divContent n' est pas bonne de même avec msg !!!
Une idée ???
Ouais mais 1 try appelle 1 catch. Et je voulais, ici, 1 catch par erreur possible : connexion échouée, sélection de la db échouée, etc...
Tu remarqueras que dans d'autres méthodes, je n'utilise qu'1 try, parce que je ne veux intercepter qu'1 erreur (si j'échoue dans l'ouverture d'un fichier...une fois ouvert, j'arriverai à le lire à priori).
Oui, effet ca m'a fait prendre conscience que je faisais les choses de facon un un trop "laxiste" qq fois.
Mais bon pour des élements constants, qui ne sont pas omdifier je ferai pas de modifications, mais pr les elément variables et qui plus est accessible par methodes GET ou POST , là c'est sure c'est indispensable!
j'y retourne de ce pas!
Sinon, y a quand meme qq chose qui me chagrine dans ton code, c'est la succession de try justement.
En effet ici tu n'utilise pas les avantages de try par rapport au if.
Le try permet d'essayer plusieurs lignes de commandes successives avant d'arriver a un evantuel echec.
Alors que le if essaye un element, par un element.
concretement:
try 1
try 2
try 3
=>
if 1
if 2
if 3
try 1 2 3
Voila, mais bravo pr ta source et ton partage!!
a+
plait-il...? Se passer des vérifications en se disant que de toutes façons, en prod, on ne doit pas avoir d'erreurs ?
Mais, si tu ne fais aucune vérification, donc aucun try catch ou autre...et que ton code, globalement, se retrouve avec une mauvaise variable quelquepart : tu auras une erreur, en prod aussi. Une erreur interne à PHP, mais qui sortira. quand même. Et ton code ne marchera pas.
Si on suit ce que tu dis, autant coder sans jamais faire de vérification. Aucune.
"En effet une fois le code mis en place, la classe utilisée a bon escient, on reverifie toujours tout, alors que le code ne change pas... ??"
=> mais le code change tout le temps...? Tu peux le faire évoluer sur la même page, changer les paramètres...etc. Sans parler de pages différentes.
Il ne faut pas confondre optimisation et laisser-aller! Tu ne peux JAMAIS être sûr à 100% que ton code recevras toujours les bons paramètres. Parce que généralement, un code est alimenté par un autre code, lui-même dépendant d'un 3ème etc...
Ma façon de coder est efficace...la preuve : en production, mes serveurs sont quand même en error_reporting (E_ALL). Et je fais des sites grand public, pour de grosses boîtes.
Donc non, je ne suis pas d'accord avec toi ;-) Ca n'alourdit pas le code, au contraire, à la lecture, on voit tout de suite ce dont on a besoin. Et ça ne le ralentit pas, parce qu'un try ou un if ( isset ()), ça ne bouffe pas trop de ressource. Et parce qu'à côté de ça, j'optimise quand même pas mal...
Mais au vu de cette classe je m'interoge un peu de l'utilité de toute ces verifications.
En effet une fois le code mis en place, la classe utilisée a bon escient, on reverifie toujours tout, alors que le code ne change pas... ??
je comprend que tout ces messages d'erreur peuvent aider le développeur utilisant ta classe, a comprend ou est son erreur eventuel, mais apres aucune erreur ne doit subvenir, en production. Si y en a une ce serai un hackage!.
Donc voila est ce que ca ralonge pas trop la procedure au point de devoir justement utiliser ton systeme te permetant de passer outre les time limit.?
Personnelement, je m'oriente aussi vers une programation assez bien ecrite dans le genre, mais au contraire, je ne fait pas trop de verification qui a mon sens alourdisent le code et le complique.
Mais c'est vrai que le system de __set est plutot pas mal vu!
Concretement : est-ce que en fonctoionnement on passe plus, par ces verif là et que les variable sont assigné directement..?
__set () est une méthode magique pour créer un setter.
A savoir que je passe par là pour permettre (ou non) l'initialisation de propriétés privées (ou protégées).
De plus, cela permet d'être un peu plus clair éventuellement.
Ici par exemple, j'ai un tableau comme propriété privée(noTimeOut::aProps), contenant des clefs et des valeurs.
Avec le setter, au lieu de permettre ceci :
$oNTM -> aProps['DB'] = 'MYSQL';
qui serait l'initialisation logique
Je permets ceci :
$oNTM -> DB = 'MYSQL';
ce qui est plus intuitif.
De plus, il me permet de vérifier éventuellement les valeurs assignées.
Dans le cas de DB, je n'autorise que 2 valeurs : MYSQL ou MSSQL.
PS : pour comprendre le code, il faut aussi lire la classe js, et les fichiers dans le répertoire scripts/ voire les indexN.php lol...
$oNTM
Par contre il y a un objet javascript dans le fichier, alors si quelqu'un est calé dans ce domaine, je veux bien des critiques dessus aussi! Parce que la POO javascript, ce n'est pas ma spécialité...!
Les try catch, c'était pour te faire plaisir en plus (si si!).
Pour la fonction 'null' oui tu as raison, c'est une bonne idée.
pour la propriété $aProps, nan, je préfère comme ça parce que ça me permet de centraliser mes propriétés pour tester le __set (). Et une constante de classe ne peut pas être un tableau, malheureusement.
Et le while (), oui, c'est un oubli. Ca ne marchait pas au début, alors pour tester j'ai mis la fonction en dur, puis j'ai trouvé ce qui n'allait pas, et j'ai oublié de la remettre lol.
Et je n'utilise pas d'objet db parce que c'est juste la 1ère version : à terme, je vais en mettre un. Mais là c'est juste que j'avais besoin de quelques fonctions bien précises. Je n'ai pas terminé ce code, je compte le rendre plus fonctionnel; mais je dois le tester à fond sur mes codes d'abord. Et trouver à quelles occasions il peut être utilisé, celles-ci mises à part.
Pi avant j'ai toujours un problème avec les fichiers XML. Le flushing par motif fonctionne bien...sauf dans le cas d'un XML complexe contenant des caractères invisibles : la taille du fichier, et le nombre de caractères renvoyés ne correspondent plus, du coup javascript et php ne sont plus d'accord, n'ont plus les mêmes offset, et j'ai des décalages :-(
Et comme à la base je veux l'utiliser pour du xml, ce truc...(mon debugger en fait : je sors le contexte de la page débuggée, et ce contexte peut-être énorme! Donc, cette appli me permettra de l'afficher quand même sans problème; mais je n'y suis pas encore tout à fait).
Merci en tous cas, je ferai tes modifs tout à l'heure :-)
t'as oublié un call_user_func pour le fetch_assoc dans le cas de mssql au lieu de mysql ^^
D'ailleurs, j'ai toujours pas compris pourquoi tu utilisais pas un objet de db au lieu d'un truc comme ca :p
Question code (bah oui, moi jvois que ca en ce moment ^^ ) :
(l. 67)
if (is_null ($this -> aProps['DB']) || is_null ($this -> aProps['HOST']) || is_null ($this -> aProps['LOGIN']) || is_null ($this -> aProps['PWD']) || is_null ($this -> aProps['QUERY']) || is_null ($this -> aProps['DBSERVER']) || is_null ($this -> aProps['START']) || is_null ($this -> aProps['STEP'])) {
huhuhuhu ? T'en as pas eu raz le bol d'écrire tout ca ? ;)
T'aurais pu faire un truc dans le genre :
private static function are_null() {
$num_args = func_num_args();
for ($i=0; $i<=$num_args; $i++ ) {
$arg = func_get_arg($i);
if ( is_null($arg) ) return true;
}
return false;
}
// Que tu appèles comme ca :
if ( self::are_null($var1, $var2, $var3, $var4 ...) ) throw new Exception('...');
// Voila :)
// Suivant : (l. 26)
private $aTypes = array('...');
huhuhu, $aTypes n'est pas fait pour être changé ! Donc ==> constante !
Y'a peut être encore 2 ou 3 trucs mais j'hésite :p
Cependant, bonne classe. J'aime bien l'utilisation du try{}catch{} ^^
Ca peut fonctionner pour la génération d'un mega fichier zip ?
- Messages postés
-
10840
- Date d'inscription
- lundi 24 février 2003
- Statut
- Modérateur
- Dernière intervention
- 2 mars 2010
21En fait, ça ne sert à rien si ce n'est à perdre des ressources pour rien...faudra que je recode ça.
Alakhnor => l'utilisation de ces classes passent nécessairement par une revisite de ton code. Il faut le voir autrement : la boucle est gérée par du javascript, c'est tout.
Poutr php4, tu dois pouvoir réécrire la classe php...à priori. Rien de vital ne tire partie des spécificités PHP5.
- Messages postés
-
2350
- Date d'inscription
- mercredi 13 octobre 2004
- Statut
- Membre
- Dernière intervention
- 18 avril 2015
3Enfin si, mais au niveau des try{}catch() non.
J'aurais dégagé les try{}catch() des méthodes pour commencer.
Théoriquement, le try{}catch() se fait lors d'un appel de méthode et pas dans la méthode elle même. Sauf si c'est pour appeler une méthodes privée/protégée.
Ex :
# public function __set ($sType, $sVal) {
# try {
# if (!array_key_exists ($sType, $this -> aProps)) {
# throw new Exception ($sType.' is not a valid property');
# }
# } catch (Exception $e) {
# echo $e -> getMessage ();
# }
Ce que j'aurais fait :
public function __set($var, $val) {
if ( !array_key_exists($var, $this -> aProps) )
throw new GetSetException($var, 'set');
// suite...
}
Et quand tu appèles ta classe de l'extérieur :
try {
$maclasse = new noTimeOut;
$maclasse->timeout = 360;
// etc..
} catch ( GetSetException $gs ) {
die ( $gs->getMessage() );
} catch ( Exception $e ) {
die ( $e->getMessage() );
}
Par contre (voila la suite ^^) :
#public function flushMe ($aWork = null) {
# try {
# switch ($this -> aProps['TYPE']) {
# case 'DB':
# if (false === self::isNull ($this -> aProps['DB'], $this -> aProps['HOST'], $this -> aProps['LOGIN'], $this -> aProps['PWD'], $this -> aProps['QUERY'], $this -> aProps['DBSERVER'], $this -> aProps['START'], $this -> aProps['STEP'])) {
# throw new Exception ('DB properties have not been fully defined');
# }
# $mTmp = $this -> getDB ();
# break;
switch ($this -> aProps['TYPE']) {
case 'DB':
if ( !self::isNull ($this -> aProps['DB'], $this -> aProps['HOST'], $this -> aProps['LOGIN'], $this -> aProps['PWD'], $this -> aProps['QUERY'], $this -> aProps['DBSERVER'], $this -> aProps['START'], $this -> aProps['STEP']) )
throw new IssetException('DB');
try {
$mTmp = $this -> getDB ();
} catch ( Exception $e ) {
die ( $e->getMessage() );
}
break;
// Etc...
try {
$maclasse = new noTimeOut;
$maclasse->timeout = 360;
$maclass->flushMe();
// etc..
} catch ( GetSetException $gsE ) {
die ( $gsE->getMessage() );
} catch ( IssetException $iE ) {
die ( $iE->getMessage() );
} catch ( Exception $e ) {
die ( $e->getMessage() );
}
Voila comment je l'aurais joué. J'aurais étendu la classe d'exception pour chaque cas :)
Autrement, ton try{}catch() ne sert pas à grand chose dans une classe :)
- je dois développer en php4
- mon programme est une boucle effectuant un certains nombre de traitements incluant des requêtes vers FlickR calculées par le reste. Je ne vois pas trop comment déporter des traitements et les traiter dans la classe php.