'out' question dans VB.NET

Question

Quand en C#, nous avons les options de paramètres out et ref, en VB il y a une seule: ByRef.

Maintenant, peu « problème » en essayant de « éliminer » l'avertissement du compilateur dire que test n'a pas été initialisé avant de passer comme argument:

Dim test As MyParsableClass ' = Nothing need imperatively?? ' 
' some code ... ' 
MyParsableClass.TryParse("value", test) ' warning on "test" here 

la classe brève déclaration:

Class MyParsableClass 

    Public Shared Function TryParse(ByVal value As String, _ 
    ByRef myParsableClass As MyParsableClass) As Boolean 
    myParsableClass = Nothing 
    If True Then 
     ' parse code OK' 
     myParsableClass = New MyParsableClass() 
     Return True 
    Else 
     ' parse code NOK ' 
     ' myParsableClass remains Nothing ' 
     Return False 
    End If 

    End Function 

End Class 

peut-être une solution était de déclarer

...Optional ByRef myParsableClass As MyParsableClass = Nothing) 

mais je ne peux pas définir ce paramètre comme facultatif. Que se passera-t-il si je le rate?

PS. (modifier) ​​

Dans le projet réel, ma classe « analysable » est MyHour avec Hour et Minute propriétés. J'ai écrit déjà le Parse(value as String) avec un FormatException, mais je pense que le code pourrait être plus clair, compact et rapide quand je ne vais pas utiliser essayer blocs catch ...

Answer 1

Je ne crois pas qu'il soit possible d'empêcher cet avertissement, sans affectation explicite.

Différentes langues ont des caractéristiques/installations différentes - si ce n'était pas le cas, il n'y aurait qu'un seul langage de programmation :-) Dans ce cas, oui, VB ne prétend pas qu'il existe deux types de paramètres ref, comme C# fait - en ce qui concerne le CLR, "out" n'existe pas.

Je ne suis pas sûr de ce que peSHIr parle - TryParse a été ajouté à des versions ultérieures de la BCL précisément la situation dans laquelle une analyse syntaxique est aussi susceptible d'échouer pour réussir - de sorte que vous pouvez prendre un chemin formation de failles sans avoir besoin d'une exception pour être jeté.

Modifier

Pour ajouter - la raison pour laquelle vous ne recevez pas un avertissement pour un grand nombre de types intégrés pour lesquels existe TryParse (par exemple Int32) est parce qu'ils sont types Structs/valeur, et donc toujours avoir une valeur. Si votre classe est assez simple, serait-il logique qu'elle soit une structure à la place?

Answer 2

Pas exactement une réponse à votre question, mais out and ref/ByRef are bad, alors pourquoi les utiliser en premier lieu? Beaucoup de développeurs pensent que le paradigme TryParse dans .NET Framework 1.0 était un mauvais choix. Pourquoi ne pas opter pour un MyParsableClass qui a une méthode Public Shared Function Parse(ByVal value As String) As MyParsableClass qui déclenche une exception appropriée en cas de besoin?

Ou même un Public Shared Function Parse(ByVal value As String) As MyParsableClassParsed où, MyParsableClassParsed est une aide classe interne qui contient deux propriétés: Success As Boolean et readonly Result As MyParsableClass? Vous pouvez toujours obtenir un résultat en appelant Parse, mais vous obtiendrez Success==True et Result==[whatever], ou simplement Success==False et Result==Nothing. Votre classe auxiliaire MyParsableClassParsed peut également utiliser un énumérateur au lieu d'un booléen et/ou une liste de messages d'erreur pour indiquer à l'appelant comment/pourquoi l'opération d'analyse a échoué. Ou l'exception de lancement peut avoir une telle valeur énumérée et/ou message (s) d'erreur.

Beaucoup plus facile à utiliser et plus flexible. Et tout sans ByRef pour vous donner des maux de tête/avertissements.