Apprenez la difference
A priori, on faites tous de l'orienté objet, chose que tu n'as pas l'air de connaitre...
0 et null sont des concepts qui existent dans a peu près tous les langages, ton truc c'est du pseudo php. c'est pas parce que tu sais faire que 3 merdes en web que tu dois venir te la raconter.
C'est bon tu comprends mieux ?
Je pratique la programmation depuis, mmmh attends, 1986. Tu veux m'expliquer des choses ? vas y je t'attends.
Ben apparemment, il faut que tu apprennes que le null, c'est la base de l'orienté objet...
Tu fais exprès ou tu comprends rien ? Tu veux un cours ? Je t'explique ce que c'est null et pourquoi c'est le mal ?
null c'est quelque chose qu'on ne manipule jamais. on ne doit pas l'accepter en entrée d'une methode ni le retouner en retour d'une méthode. Sinon à l'execution (au runtime) ca plante salement. A la place, on gère proprement les entrées d'une méthode et on ne retourne jamais null. Par exemple si tu fais User user = User.findByEmail("[email protected]") et qu'il n'y a pas de résultat, tu dois retourner une instance de User pour que le code appellant puisse faire if ( user.exists() ) { do something } et pas qu'il retourne null et fasse user.truc() car tu appellerais une methode sur null et ton programme va planter. Avec cette manière de faire tu évites toute erreur à l'execution et le code est plus explicite. C'est l'exemple que j'ai donné en dessous qui a pris -8 points. Un code dans n'importe quel langage qui crache des erreurs sur null est un mauvais code.
Ha oui, je comprends mieux...
En fait, tu ne sais juste pas utiliser le null.
Un bon programme ne plante pas face à un null, car il teste justement à null avant d'appeler une méthode de l'objet. En java, la plupart des méthodes du jdk ont cette pratique, qui devrait être commune à tous les devs.
Dans ton exemple de recherche, le null caractérise justement l'absence de User. Si tu renvoies un User, c'est que tu en as trouvé un. Je sais pas ou tu as appris la programmation, mais ton prof de logique était vraiment à l'ouest.
Un méthode renvoie null si elle est sensé rien renvoyé, et renvoie quelque chose quand elle est sensé renvoyer quelque chose; c'est le principe de l'objet...
Je te prend comme exemple, le simple Integer:
null = absence de donnée
0 = donnée à 0
1 = donnée à 1, etc...
Ta logique de renvoyer quelque chose est vraiment déficiente (sans vouloir critiquer hein). Car tu supprimes l'un des intérêts de l'objet.
D'ailleurs, je me demande, si tu retournes une instance de User, comment tu détermines que t'en a pas trouvé? Tu vas foutre un boolean found dedans?
D'ailleurs, j'ai envie de dire, le test unitaire de base, c'est testé si on reçoit null ou un objet instancié, suivant que l'on veut ou pas avoir une donnée en retour... Tous les framework de test unitaire (JUnit par exemple), ont un truc du style Assert.assertNotNull(). Simplement parce que c'est la base de l'orienté objet...
Ahahah tu m'amuses. Vas te coucher tu dis n'importe quoi.
Comment je determine que je n'ai rien trouvé ?
class User {
static User NOT_FOUND = new USER() ;
static findByEmaIl(String email) {
User user = User.findFirst("truc);
if ( user == null ) {
return NOT_FOUND ;
} else {
return user ;
}
}
exists() {
return this != NOT_FOUND;
}
}
ok. c'est bien. Je fais du java depuis la version 1.0 .. j'ai codé dans tous les langages depuis 86. je suis architecte logiciel depuis 12 ans dans des grosse boites, mais tu as surement raison. excuse moi de vouloir t'instruire.
On le manipule pas en objet, mais par exemple en C c'est courant...
Et pour les autres voici ce qu'il entend : https://en.wikipedia.org/wiki/Null_Object_pattern
http://stackoverflow.com/questions/1274792/is-returning-null-bad-design
http://stackoverflow.com/questions/261015/where-can-i-see-the-source-code-of-the-sun-jdk
Ta logique de renvoyer quelque chose est vraiment déficiente (sans vouloir critiquer hein).<== tu as déjà entendu parler des "Option" en Scala ?
Mhh, je suis pas fan.
Ha, et j'ai un âge similaire au tiens, aussi avec le même job. Mais j'ai pas besoin d'afficher ma bite pour me sentir supérieur...
Et pour le coup, je préfère une méthode static exist(User user) dans ta classe User. Qui elle, teste à null.
Je vois que ca a été implémenté en Java 8. J'en suis toujours à Java 7 pour le moment, sauf pour un projet. Mais je n'ai pas encore utilisé.
@rabbit @Geraven
Alors je vais couper la poire en deux et mettre tout le monde d'accord.
Une méthode ne devrait jamais accepter null en paramètre : ça n'a aucun sens, on ne travaille pas avec quelque chose qui n'existe pas.
On ne manipule pas les nulls en effet, sauf quand éventuellement on assigne null à une variable quelconque, histoire de dire qu'elle existe et qu'on en réserve l'espace, ça évite un plantage quand on veut l'utiliser et qu'on a oublié d'assigner la valeur (c'est à dire que le programme plante quand même vu qu'il trouve ton null, mais au moins il ne risque pas de tourner avec une valeur aléatoire qui trainait dans la mémoire).
Une méthode ne renvoie JAMAIS (ou ne devrais jamais renvoyer) null / NULL.
Pourquoi ? D'abord si une méthode ne renvoie rien, elle ne renvoie pas null non plus (oui parce que je suis désolé, mais renvoyer une variable == null c'est renvoyer quelque chose quand même !) , elle est en void et tu fais éventuellement un return; pour le faire sortir de la fonction / méthode. C'était le cas du void.
Dans le cas ou ça se passe bien, la question ne se pose pas : tu renvoies un objet, une valeur, un true, bref, quelque chose.
Dans le cas ou ça ne se passe pas bien, tu va renvoyer un erreur ou une valeur quand même : la fonction a pu échouer pour de multiple raison, l'idée c'est quand même de dire pourquoi elle a pas marché, qu'on puisse corriger le tir ! Donc tu va renvoyer un false, un 0 , une erreur via un throw, ou éventuellement si tu bosses en POO un objet "vide".
Je dois dire que dans le cas ou tu fais de la POO, je suis PAS DU TOUT fan de renvoyer un objet vide, tout ça juste pour pouvoir faire "monObjet.exist()" et tester une merde de ce genre ... non non non ! Fout ton code dans un Try Catch, et renvoie une erreur dans ta fonction ! L'objet vide ça marche seulement si le gars fait le .exist() , et tu ne peut pas en être sur, et en plus ça ne t'expliquera pas pourquoi la fonction n'a pas marché correctement.
En plus, si tu met un throw et que le mec ne met pas un try catch, le compilateur va le lui dire en principe, ou au moins afficher un truc du type " Warning : Uncaught Exception ".
J'ai 25 ans, je fais de l'informatique depuis que j'en ai 10 et je programme depuis 4 ans, et si t'es pas d'accord c'est pareil.
Mais si t'es pas d'accord, explique moi quand même pourquoi !
Je suis pas d'accord mais il est tard et j'ai du travail demain.
Je ne vais pas reprendre tout ton texte.
Mais tu veux utiliser un try { } catch {} pour gerer une NPE est c'est pas bien, tout
simplement parce qu'une exception c'est un cas exceptionnel. Alors que ne pas
trouver un utilisateur par son email c'est un cas courant. C'est bien pour cela que
j'utilise cette pattern.
Pour le fait que tu n'aimes pas monObject.exists() : tu preferes
User user = User.findByEmail("anus") ;
if ( user != null ) {
user.plop()
}
ou
User user = User.findByEmail("anus") ;
if ( user.exists() ) {
user.plop()
}
---
La version 2 est bien plus implicite.
Sur ce je vais me coucher :)
---
PS: J'ai 38 ans j'ai commencé à 6 ans :P et c'est pas un concours de bite.
Et pourtant moulte language utilise les exceptions en leur sein sans qu'on sans rend compte ... je suis d'accord avec @No_Offense sur ça vision ;), une exception ce n'est pas forcement un "OH MON DIEU ARRETE TOUT DE SUITE LE PROGRAMME".
Throw une exception alors que tu n'as pas d'exception? Je suis pas fan. Une exception, c'est sensé symboliser une erreur... Ne pas trouver quelque chose, c'est pas nécessairement une erreur. Évidemment, cela dépend des besoins.
Bin perso, tu passes un paramètre à une fonction, tu essayes de travailler avec ce paramètre, et il est en null ? C'est anormal comme comportement ... Et si c'est normal, alors la fonction le gère et tu renvoies pas d'exception. Je prends le cas d'un booléen : True si ça marche, False si ça a pas marché mais pour des raisons connues & gérées , Throw Exception si c'est un comportement exceptionnel.
Ce que je veux dire c'est que renvoyer null en deux mots, c'est un truc de branleur.
T'as AUCUNE information avec ça, et du coup tu ne sais rien en faire, et si c'est un utilisateur qui tape l'input (et qu'il a pas été pris en compte cet input, pour X raison) , tu renvoie null, ça plante ou il va recommencer et ça marchera toujours pas, et ça se mords la queue. Alors que si tu renvoies false parce que y'a un cas ou on sait que ca foire, bah tu fais un message d'erreur personnalisé, et si tu throw une exception bah pareil y'a un message d'erreur personnalisé.
En plus je pense que certains langages vont te renvoyer null d'eux même si la fonction plante.
Par exemple tu fais une moyenne avec des int qui n'ont pas de valeur, ton return maMoyenne va renvoyer quoi ? peut être bien un int null.... (Selon les langages et la fonction utilisée pour faire la moyenne).
En fait une exception c'est un comportement qui n'était pas prévu hein, ça s'arrête là, et dans ma logique, tu manipules pas du null. Maintenant si ça a été prévu, bah fais le moi je m'en fous, mais ne renvoie pas un null dans ta fonction quoi ...
Je suis d'accord que la V2 est plus explicite, mais ça justifie pas le renvoi d'un null en fonction pour moi ...
D'abord je suis pas trop d'accord avec ta vision des exception. On est tous d'accord pour dire qu'on manipule pas des null (même toi tu t'en sers dans ton exemple que pour un test d'existence ...) , du coup je pense qu'on sera aussi d'accord pour dire qu'une fonction qui devait travailler avec un truc et qui se retrouve avec un null, bah c'est pas normal => donc exceptionnel .... Je dis pas que ça va faire planter ton programme, ou que tu va l'arrêter, je dis que c'est pas le comportement classique attendu.
Partant de la pour moi t'as 2 choix, ou bien tu sais pourquoi ce comportement s'est produit, parce que tu sais qu'il y a un cas précis ou ça peut arriver, et tu gère ce cas dans ta fonction, du coup je t'invite à renvoyer une autre valeur que la valeur normale de la fonction (false au lieu de true, -1 au lieu de 1 si c'est un int toujours positif, ce genre de choses), le tout pour que ton dev en aval, il comprenne tout de suite qu'il y a un souci, et qu'il puisse carrément faire réagir son code avec ça (Comme dans un try catch, sauf qu'au lieu d'être à l'affut d'une exception automatiquement, c'est le dev qui fait l'intelligent et qui est a l'affut d'un type de résultat dans les fonctions).
Soit tu renvoies une Exception, parce que c'est pas normal comme comportement. Et je pense que c'est plus propre, parce que même si ton dev qui manipule tes objets est stupide, le compilateur ou le client va lui dire " Uncaught Exception : blablablabla " et donc c'est juste beaucoup plus propre et safe ...
Je sais pas comment tu vois l'orienté objet exactement, y'a plusieurs approches selon les cas aussi...
Maintenant une des approches, c'est que t'as un dev qui fait les classes , et un autre qui manipule les objets ...
C'est deux niveaux d'accès différents, qu'on ne mélange pas ... le mec qui fait les classes c'est un senior qui sait ce qu'il fait et qui a accès à la DB par exemple, et toi tu manipuleras les objets pour interroger la DB et faire le comportement final avec les outils qu'on t'a donné. Dans un cas comme celui là, c'est très très porax de renvoyer un objet null : le mec ne sait pas ce que ça veut dire, et même s'il le sait, il ne peut pas voir ou ça a foiré dans la fonction, donc il sait pas comment éviter de le reproduire ...
D'ou le Throw Exception ... Si t'es pas content avec ça, je t'invite à faire des exceptions personnalisées qui héritent de ce genre de mécanismes, mais sémantiquement pour moi c'est correct.
Pour les exceptions aussi t'as deux approches : ou bien on laisse couler un maximum d'erreur "osef mode" et on n'envoie d'exception que quand c'est un truc qui risque de faire crash le programme.
Ou bien on renvoie des exceptions dès qu'il y a le moindre truc bizzare, et on arrête même le programme ASAP.
C'est deux approches différentes, typiquement je comparerai a WIndows & Mac ...
Mac essaye de faire son job coute que coute, quel que soit le nombre de trucs foireux rencontrés.
Windows va plutot t'afficher un warning et un message d'erreur dès qu'il rencontre le moindre problème, et souvent s'arrêter quand ça arrive.
Deux visions différentes, les deux sont bonnes, mais quand t'es dans le code et que c'est un mec qui a besoin de faire se comportement, renvoie lui l'info pour qu'il puisse changer ...
Typiquement mac sera plus intelligent pour résoudre le problème seul, le programme ira voir plus loin et sera solide.
Windows plantera tout de suite, mais il t'expliquera pourquoi ça a pas fonctionné.
Si t'as un truc qui foire sur mac, genre vraiment, t'as bien souvent zéro aide et zéro message d'erreur, du coup quand ça se produit (quasiment jamais , mais bon ) , quand ça se produit, tu peux juste essayer de réfléchir toi même très loin pour savoir où est le souci : qu'est ce que t'as mal fait ? parce que c'est ton input le souci, pas le programme, et vas y pour essayer de comprendre en quoi ton input a foiré.
Si c'est un password c'est facile : + de 8 caractères, Majuscule, minuscule, chiffre, caractère spécial.
Ou alors peut être que c'est un ces éléments qui n'est pas toléré ........ hum hum ... Mais lequel ?
Etend la problématique à des input plus complexes : c'est la merde.
Le null symbolise l'absence d'information justement. Après, @rabbit utilise un pattern pour éviter le null, libre à toi de l'utiliser. Mais du coup, dans l'idéal, il faudrait interfacer cela, et faire étendre cela par tous les objets... Alors que le null et le test à null existe déjà.
Ma vision c'est les exceptions "fonctionnelles" (donc perso) et les exceptions techniques.Du coup pas de NULL juste un try catch UserNotFound qui est pour moi une exception fonctionnelle donc sujet un comportement différent comme toi tu fais ton if user == null ou if user.exist().
Juste un vision différente des choses ...
Je comprends le problème de compréhension entre nous. Le null n'est pas sensé symboliser une erreur, c'est effectivement l'exception qui le fait. Dans ton exemple, le cas ou l'accès db renvoie null est le cas ou il ne trouve rien, pas quand il a eu un problème.
On est d'accord.
C'est vrai que j'ai pas pris de cas concret mais oui en général renvoyer un tableau vide ça veut dire qu'on a eu l'accès mais qu'il y a pas de données, alors qu'un null ça symbolise un problème ou une erreur pendant l'éxécution.
Maintenant idéalement, éviter de renvoyer null et gérer ce cas de figure, mais oui dans certains cas c'est "normal" ou "classique". Notamment quand on doit récupérer une série de données. Pour le cas d'un objet ou tu le manipules ou créé et renvoyer l'objet vide / null , bah justement je trouve ça très WTF parce que tu ne sais plus si il est dans cet état a cause d'une erreur d'accès ou si y'avais rien a mettre dedans.
Maintenant c'est du cas par cas évidemment... Je pense que l'idée c'est d'avoir une information sur l'erreur qui s'est produite, pour qu'on puisse éviter de la refaire (souvent tu bosses pas seul et ton pote ne sait pas forcément ou ça a planté exactement, pareil pour un utilisateur).
Ca et d'avoir toujours le même principe dans la prise de décision et dans ton code.
Ma vision c'est qu'une exception checkée est d'une part exceptionnelle et d'autre part non récupérable.
Si par exemple tu lis un fichier et qu'il est supprimé pendant ce temps, tu vas lever une exception checkée qui est non récupérable. A ce moment la tu wrappes dans une RuntimeException qui va se propager jusqu'au point de traitement des exceptions. (Dans ce cas ci, tu peux la logger et informer l'utilisateur)
Par contre, le fait de ne pas trouver un utilisateur n'est pas exceptionnel, c'est un cas que tu vas rencontrer plein de fois.
La version avec exception c'est
try {
User user = user.findByEmail("anus");
user.plop()
} catch(UserNotFoundException e) {
// la le dev de base il s'en bat les couilles il logge
// ou pire il la throw
}
La version sans exception c'est :
User user = user.findByEmail("anus");
if ( user.exists() ) {
user.plop();
} else {
// La tu te dis bien qu'il faut faire quelque chose
}
Null c'est mal. C'est isEmpty() et if ( notEmpty() ) { return paperRoll.lenght ; // 0 }
je vois pas trop le rapport. J'ai lu les messages du haut, et j'ai l'impression que vous avez tous oublié que null c'est juste l'état d'un "pointeur" qui ne contient pas d'adresse. Bon mes connaissance se limitent au java, c#, c et c++, si dans d'autre langage il est interprété différemment je ne suis pas au courant.
Tu ne dois accéder à ce site que si tu as au moins 18 ans ou si tu as l'âge légal pour visionner ce type de matériel dans ta juridiction locale, l’âge le plus élevé étant retenu. En outre, tu déclares et garantis que tu ne permettras aucun mineur à d'accéder à ce site ou à ces services.
En accédant à ce site, tu acceptes nos conditions d'utilisation.