Quand ne doit-on pas utiliser de méthodes ?

[pascal]

merci pour cette proposition qui est argumentée pour une fois

par contre, comment gérer le cas suivant :
_ les données sont bonnes, isValid() renvoie TRUE
_ mais la création plante, et createFlight() renvoie FALSE

comment gérer/indiquer avec précision le niveau d'erreur : les données ne sont pas valides ou la création a raté quand même ?

A+

Pascal

[pascal]

ha non, on ne procède pas toujours comme ça

dans ma programmation, les méthodes isXxx renvoient TRUE ou FALSE, car ce sont des conditions; et elle enregistrent les erreurs dans une liste d'erreurs, un champ de la classe.

ça permet de faire des trucs genre :

Code PHP :

<?php 

// recuperer toutes les erreurs

$objet->listeErreur->getErreurs();

// recuperer le texte d'erreur pour le champ 'name'

$objet->listeErreur->getErreur('name'); 

[naholyr]

Et les exceptions ?

Code PHP :

<?php 

class FlightIsNotValidData_Exception extends Exception {

  function __construct($data) {

    parent::__construct('Données de création du Vol incorrectes : ' . var_export($data, true));

  }

} 

[naholyr]

Bah moi je le trouve évident dans ce cas précis ^^

Le système de cascade des exceptions est un processus que seules les exceptions permettent, et qui a de nombreux intérêts de manière générale.
Mais bon chacun fait comme il veut, je m'en fous.

[pascal]

je trouve les exceptions intéressantes pour le coté try/catch ( "attrape moi si tu peux" ), mais je ne les utiliserai pas dans ce cas :
_ des données mal saisies par l'utilisateur font partie des branches possibles dans un scenario, tout comme le scenario optimal. dans ce sens, il doit y avoir une gestion "classique" de ce scenario
_ try/ catch me semble plus indiqué pour des erreurs "système", typiquement si du SQL plante.

ceci dit, je veux bien d'autre arguements pour/contre leur utilisation.

A+

Pascal

[Sephi-Chan]

Finalement, j'aurais dû faire ce post dans la partie débats, il prend une tournure à laquelle je ne m'attendais pas tout en étant intéressant.

Je remercie en tout cas ceux qui m'ont aidé, que ce soit en privé ou en public.

Concernant la gestion des erreurs, je trouve ça un peu bâtard : Voyons par exemple un script d'authentification : J'utilise un formulaire qui, à la soumission (ou autre), met en évidence les champs pas ou mal remplis par Javascript. J'aimerai que graphiquement, le résultat soit le même si l'erreur est détectée par PHP. C'est difficile à faire avec ce que vous présentez.

Exemple d'une telle page (non fonctionnelle, il n'y à que du Javascript dedans. Je crois qu'elle n'est pas compatible avec IE) : http://seelies.admin-level.net/javascript/


Sephi-Chan

[Sephi-Chan]

C'est clair que c'est pas trivial du tout avec ce que tu proposes (return -1) ! Il faut gérer le réaffichage du formulaire (après redirection) avec les styles/messages qui vont bien.

[uriak]

Pour mon site, j'ai pour l'instant construit mes classes de news et de login avec dans l'idée de pouvoir tracer tous les bugs et erreurs utilisateurs.

En gros la classe possède une méthode error qui prend un entier, toutes les autres méthodes appellent error($id) si nécessaire. Error concataine ce qu'il faut dans une variable de classe, $errorLog. A la fin du traitement d'une page, j'appelle une méthode Flush() qui me renvoie $errorLog ce qui me permet d'afficher toutes les alertes qui ont eu lieu.

Je pense qu'en détournant un peu ce principe, on doit pouvoir gérer des trucs plus avancés...

[Roworll]

En général mes traitements renvoient du XML.
De cette manière, je peux récupérer et traiter les informations de retour via PHP, XSL ou même Javascript/Ajax selon les besoins.

[Sephi-Chan]

Pourrais-tu nous montrer un peu ce à quoi ressemble tes envois d'erreurs et surtout leur réception alors ? Car ça semble intéressant.

Toujours est-il qu'il me semble presque impossible de faire des redirections par header et de sortir du texte en retour, ça repose toujours sur des solutions un peu bancales de sessions ou autre... :'(


Sephi-Chan