Est-il possible d'"auto-détruire" un objet dans son propre constructeur ?

Bonjour,

je débute en C# et je n'ai pas trouvé le moyen de faire cela dans les différentes docs : j'aimerai pouvoir retourner une référence nulle lors de la construction d'un objet si une erreur se produit (et ne pas lever d'erreur).

L'idée est que si la construction de l'objet echoue, aucune erreur n'est levée mais une reference nulle est retournée. Charge à l'appelant de vérifier que l'objet construit n'est pas nul et de faire ce qu'il veut en fonction de cela.

En Perl, ce comportement est très courant... est-ce possible d'en faire autant en C# ?


merci pour toute réponse
Bonne journée

A part lever une exception dans le constructeur je ne vois pas. Et puis l'exception ça te permet de connaitre le type d'erreur, alors que simplement renvoyer null n'est pas très informatif je trouve.

Dans le constructeur tu ne peux pas, la seule manière c'est de lever une exception. Mais ce n'est pas un problème, il te suffit de faire une méthode statique qui fera ce que tu veux ;)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

public static MaClasse TryCreateInstance() { MaClasse instance = null;   try { instance = new MaClasse(); } catch (Exception ex) { // Traitement de l'erreur éventuellement (log, ...) }   return instance; }

---

Maintenant je suis assez d'accord avec la remarque de The_badger_man.

Pour faire ce genre de choses proprement, je te conseillerais d'implémenter une Factory, cela t'évitera ce genre de bisareries ;)

Factory est un design pattern relativement simple, qui consiste à déplacer la construction des instances dans une autre classe. Ta factory construit l'objet et catche les eventuelles exception. En catche, tu fais juste 'return null' dans le reste, return la nouvelle instance.

Merci pour vos réponses. Je vais m'intéresser à la Factory.

Pour répondre à The_badger_man, il y a des cas où l'erreur doit absolument être silencieuse et ne pas interférer le déroulement (même pas par un message). Je prévois un traceur qui lui, enregistre les erreurs en détail. Libre à l'appelant d'aller voir ce qui ne va pas dans ce traceur et d'afficher l'erreur.

C'est comme ça que fonctionnent nombre de modules (orientés objets ou pas) en Perl.

Etant donné que la plupart des créations d'objets se passe bien, il me semble mieux de retourner systématiquement une référence non nulle et de spécifier les cas d'erreurs par une exception. Sinon, il faudrait faire systématiquement A a = new A() ; if (a != null) { ... }, ce qui me semble lourd. Ca impose de traiter l'erreur au plus bas niveau, alors qu'une exception peut être catchée très haut.

C'est probablement une question d'habitude :) Mais j'ai déjà vu des codes bourrés de tests de nullité inutiles, c'est assez traumatisant.

Je comprend le point de vue.
J'ai pris l'habitude de faire comme ça, et comme je suis en phase d'apprentissage, je me posais la question pour faire le corrolaire avec des scripts en Perl.

A l'usage, je ferai peut être différemment. Cela dit, je reste convaincu que dans certains cas, je n'ai pas envie de connaître la cause de l'erreur.

Lors de la programmation, c'est évidemment indispensable. Mais lors de l'utilisation par le client - toujours dans certains cas spécifiques d'utilisation -, si je sais que le programme n'a pas d'erreurs (bugs, paramétrages), le fonctionnement général du programme n'a pas à prendre en compte le fait que certaines actions n'aient pas abouties.

Après, ça dépend bien sur de l'objet créé (typiquement, ce n'est pas un objet critique mais une donnée qui sert à alimenter autre chose).