Discussion :

[Franck.H]

Je me posais cette question... J'ai un constructeur de ce genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
    Public Sub New(ByVal CsvFilename As String)
 
    End Sub

Existe t-il un moyen pour annuler l'instanciation de la classe si par exemple l'argument n'est pas fournit au constructeur ? Donc en somme, au lieu que l'objet soit créé, qu'il reste à Nothing.

[mactwist69]

Bonjour,

Directement je ne sais pas, mais je sais que j'ai déjà utiliser des Factory qui s'occupe de retourner des instanciations de classes, et à ce moment, c'est donc possible.

Un truc du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Public class Factory
 
Public Function Classe1(byval parametre1 as string) as BLL.Classe1
 
    If String.IsNullOrEmpty(paramtre1) Then Return Nothing
    Return New BLL.Classe1(parametre1)
 
End Sub
 
Public Function Classe2() as BLL.Classe2
 
    Return New BLL.Classe2()
 
End Sub
 
End Class

[Franck.H]

Merci pour cette astuce, ce qui m'a donné l'idée de faire ceci au sein de la classe elle-même avec le constructeur en privé:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
    Public Shared Function SetInstance(ByVal CsvFilename As String) As ExportSANDRE
        If Not String.IsNullOrEmpty(CsvFilename) Then
            Return New ExportSANDRE(CsvFilename)
        End If
 
        Return Nothing
    End Function

Un peu à la manière d'un singleton en fait.

[Pol63]

pour annuler la création d'une instance la seule méthode est de générer une exception

ici vu que c'est un problème d'argument tu pourrais faire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
if CsvFilename = "" then throw new ArgumentNullException("CsvFilename est vide")
if system.io.file.exists(CsvFilename) = false then throw new ArgumentException("le chemin n'existe pas " & CsvFilename)

c'est ce qui est fait un peu partout dans le framework
par contre l'appelant se prend une erreur donc il lui faut un try catch

sinon la méthode du factory fonctionne aussi, à savoir ne pas appeler le new directement mais appeler une fonction qui fera le new si c'est nécessaire
dans ce cas par contre on a plutot tendance à mettre le sub new en private (ce qui évite de pouvoir l'appeler et force l'utilisation du factory) et on met le factory en shared function sur la classe elle même (le private sub new y est accessible de là)

[Franck.H]

Salut, l'exception me va bien, si elle permet en effet d’interrompre l'instanciation de la classe. L'utilisateur ne sera autre que moi donc je saurais qu'il faut que j'englobe l'appel par un blot try...catch.

[mactwist69]

Je trouve un peu dommage d'utiliser les exceptions pour cela pour :

1) Il faut en effet faire un Try-Catch chez l'appelant... pas très jolie
2) la création d'un exception peut être plus ou moins longue en fonction de la taille de la pile d'appel...

[Pol63]

c'est un choix selon le reste de l'application
si ceci n'est pas censer arriver et qu'on log les erreurs le throw est bien, ca permet de regarder les rapports d'erreurs et donc de corriger le bug
si ceci peut arriver alors lever une exception est un peu dommage en effet

[Franck.H]

Ce n'est effectivement pas censé arriver car le programme qui utilisera cette classe fera déjà un test en amont mais je préférais mettre une sécurité en plus, on ne sais jamais.

[mactwist69]

+1 pour le throw alors

[Franck.H]

à tous !