ENVOI D'EMAILS AVEC LES CLASSES .NET - MAIL MESSAGE
oximoron
Messages postés
149
Date d'inscription
mercredi 23 juillet 2003
Statut
Membre
Dernière intervention
30 janvier 2009
-
22 janv. 2008 à 13:19
ajouini Messages postés 1 Date d'inscription samedi 27 avril 2013 Statut Membre Dernière intervention 2 mai 2013 - 2 mai 2013 à 19:22
ajouini Messages postés 1 Date d'inscription samedi 27 avril 2013 Statut Membre Dernière intervention 2 mai 2013 - 2 mai 2013 à 19:22
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/45487-envoi-d-emails-avec-les-classes-net-mail-message
https://codes-sources.commentcamarche.net/source/45487-envoi-d-emails-avec-les-classes-net-mail-message
2 mai 2013 à 19:22
14 août 2010 à 20:07
14 août 2010 à 02:41
14 août 2010 à 02:38
Ou trouver le mail.ini car cela me fait une erreur ..
Merci
13 juil. 2009 à 00:03
Si j'ai bien suivi le débat.
J'apporte ma connaissance à ce sujet.
Les règles disent qu'il faut vérifier l'état des variables saisies par l'utilisateur, ce qui est fait.
Et aussi et surtout
lors de l'utilisation d'un Stream, il faut toujours mettre l'opération entre un bloque try catch et capter l'exception. Dans ce cas, l'opération d'envoi et une opération d'écriture dans un flux de donnée, de type particulier, mais ça reste une écriture dans un Stream, pareil que dans un fichier. Donc, il faut mettre le send entre try{}catch(){}
Je vous donne le pour quoi:
Imaginer que toutes les variables contiennent les bonnes valeurs, jusqu'à la tout est bon.
Mais, tu n'es pas sure que le serveur ne va pas te répondre, alors il y aura une erreur qui va cracher l'application.
Une écriture dans un fichier est simple, ouvrir, écrire et fermer. Mais si le fichier est réservé par un autre processus, c'est le même cas ici.
Conclusion:
Vérification de variable : IF et TRYPARSE
manipulation d'un stream ==> BLOCK TRY CATCH
22 janv. 2008 à 20:31
C'est un point à considérer.
22 janv. 2008 à 20:15
string[] f=(string)(File.ReadAllText("C:\\mail.ini")).split('%');
Pour le contructeur, si tu envoi 300 mais tu va écrire les adresses l'une après l'autre séparées par des virgules.
22 janv. 2008 à 20:05
En fait ca dépent du contexte, du développeur et de l'utilisateur.
Pour en revenir au code:
les using System.Collections.Generic et System.Text ne sont pas utilisées.
Le '%' et le "C:\\mail.ini" il faut au moins mettre ca en constantes
Encore une chose :
String str = File.ReadAllText("C:\\mail.ini"); ;
String[] f = str.Split('%');
adrMail = new MailAddress(f[0], f[2]);
smtp = new SmtpClient(f[1]);
Pourquoi ne pas les mettres dans une fonction genre LoadParam() qui ne serait appelé que dans le constructeur, comme ca si je fais un evoi de 300 mails ca évite d'aller lire le fichier ini 300 fois...
22 janv. 2008 à 19:29
22 janv. 2008 à 19:11
Tu as tout à fait raison sur le fait que ce n'est pas bon de lancer des exceptions à tout bout de champs. C'est pourquoi il est très important de se poser la question : envoyer une exception ou renvoyer un code erreur.
Je vais donc parler personnellement car ce choix est à la décision de chacun.
Je pense qu'un code erreur ne peut être renvoyé que si le déroulement a été normal et surtout, si l'erreur était à prévoir pour le besoin utilisateur.
Exemple: on te demande de faire un logiciel qui va scanner un fichier formaté de telle facon tout en vérifiant les erreurs possibles (erreur de formatage d'un entier,...). Dans ce cas, il vaut mieux préférer le recours à un code erreur (int.TryParse(...)) plutot que de faire des int.Parse et catcher les erreurs.
Seulement, dans le cas de cette méthode Send(...), c'est bien plus qu'une simple erreur, c'est une erreur qui ne doit jamais arriver. C'est au développeur qui appelle la méthode de vérifier au préalable.
foreach(string curAdr in listeAdresses)
{
if(!string.IsNullOrEmpty(curAdr))
Send(...);
}
Mais aussi, une raison de plus, imagines que quelqu'un utilise cette classe mais qu'il s'en fout du code de retour de la fonction. Il va croire que tout va bien alors que non. En lui envoyant une exception, tu lui indiques une erreur dans son programme: le destinataire ne doit pas être vide.
Voila ce que je pense mais c'est au désir de chacun ^^
Et pour finir, je voudrais faire une proposition qui pourrait combler tout le monde. Pourquoi ne pas enlever complétement ce test et laisser le framework faire ce qu'il veut de cet argument (à voir: http://msdn2.microsoft.com/fr-fr/library/swas0fwc(VS.80).aspx). Car après tout, ce n'est peut être pas à la fonction test de faire ce test mais plutôt à la fonction smtp.Send(mail);
Comme ça, plus de problème ^^
Bonne soirée à tous,
22 janv. 2008 à 18:21
Vous préférez
try
{
EnvoiMail()
}
catch
{
}
à ca :
bool lbEnvoiOk = EnvoiMail()
if(!lbEnvoiOk)
{
}
else
{
}
Moi je préfère le 2ème. J'ai déjà eu des cas où une exception était lancé alors que voulais traiter l'erreur moi même, mais j'ai du surchagée la fonction pour faire un test avant le throw ... C'est sur une appli pas forcément géniale au niveau du code avec des try catch dans tous les sens, impriquées, avec des throw new exeption à tous va, donc que je pense que c'est pas forcément mauvais, mais ca peut vite devenir un bordel monstre
22 janv. 2008 à 17:51
Comment améliorer un tout petit peu? On pourrait faire une classe qui dérive de System.Exception et utiliser celle ci pour que le développeur qui utilise la classe puisse filtrer les exception sur le type d'exception. (ChipotageLevel = 90).
On pourrait également mettre dans les commentaires XML une balise exception : /// <exception cref="System.Exception">Declenche une exception si aucun destinataire</exception> pour informer ceux qui utiliseront la classe qu'une exception peut être déclenché. (ChipotageLevel = 97)
Sinon c'est une source simple mais claire donc c'est bien :)
A pu qu'à mettre des commentaires XML partout! ;)
22 janv. 2008 à 17:31
22 janv. 2008 à 17:27
Histoire d'ajouter un protagoniste à votre débat, je voudrais donner mon accord pour l'utilisation de l'exception car il s'agit bien d'un traitement problèmatique qui ne devrait pas être fait, donc une exception. Comme son nom l'indique, c'est une exception qui peut arriver et doit être corriger: on ne doit pas appeler une méthode send mail avec un destinataire vide.
Cependant, (il y a toujours un mais), je voudrais ajouter un petit conseil: tu devrais tester la valeur nulle aussi et envoyé une exception typée. Cela permet aux utilisateurs de ta classe de pouvoir trier les exceptions. Et, de plus, pourquoi ne pas le faire quand le framework nous donne les outils pour ^^
Cela donne donc le code:
if(string.IsNullOrEmpty(Destinataires))
throw new ArgumentException("La liste des destinataires ne peut pas être vide !");
Enfin, ca s'appelle du chipotage à ce niveau ^^ (mais j'aime chipoter)
Bonne soirée à vous,
22 janv. 2008 à 17:21
Pour cela, je prèfère utiliser des try/catch, pour minimiser les if d'un coté, et pour montrer des fois l'utilité.
22 janv. 2008 à 16:18
Pour moi tant qu'on peut faire des tests classiques avec des if on fait ca, les try/catch c'est pour rattraper les erreurs non prévus.
Donc je reste sur ma position (pour l'instant)
22 janv. 2008 à 15:36
22 janv. 2008 à 14:16
22 janv. 2008 à 13:19