'out' проблема в VB.NET

Question

Когда в C # у нас есть опции параметров out и ref, в VB есть только одна: ByRef.

Теперь небольшая «проблема» при попытке «устранить» предупреждение компилятора о том, что тест не был инициализирован перед передачей в качестве аргумента:

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

краткое описание класса:

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

может быть, решение было объявить

...Optional ByRef myParsableClass As MyParsableClass = Nothing)

но я не могу установить этот параметр как необязательный. Что будет, если я пропущу это?

PS. (редактировать)

В реальном проекте мой класс "parsable" имеет MyHour со свойствами Hour и Minute. Я уже написал Parse(value as String) с FormatException, но я думаю, что код может быть более понятным, компактным и быстрым, когда я не буду использовать блоки try try *

Answer 1

Я не верю, что это предупреждение можно предотвратить без явного назначения.

Разные языки имеют разные функции / возможности - если бы они не имели, был бы только один язык программирования :-) В этом случае, да, VB не притворяется, что есть два типа параметров ссылки, как C # делает - что касается CLR, "out" не существует.

И я не уверен, о чем говорит peSHIr - TryParse был добавлен в более поздние выпуски BCL именно для ситуации, когда синтаксический анализ может привести к сбою, а также к успеху. ошибочный путь, не требующий исключения.

Редактировать

Чтобы добавить - причина, по которой вы не получаете предупреждение для многих встроенных типов, для которых существует TryParse (например, Int32), заключается в том, что они являются типами Structs / Value и, следовательно, всегда имеют значение. Если ваш класс достаточно прост, было бы логично, чтобы он был структурой?

Answer 2

Не совсем ответ на ваш вопрос, но out и ref / ByRef плохие , так зачем использовать их в первую очередь? Многие разработчики считают, что парадигма TryParse в .NET Framework 1.0 - плохой путь.

Почему бы не пойти на MyParsableClass, который имеет метод Public Shared Function Parse(ByVal value As String) As MyParsableClass, который вызывает соответствующее исключение при необходимости?

Или даже Public Shared Function Parse(ByVal value As String) As MyParsableClassParsed, где MyParsableClassParsed - это вспомогательный внутренний класс, который содержит два свойства только для чтения: Success As Boolean и Result As MyParsableClass? Тогда вы всегда сможете получить результат от вызова Parse, но вы получите Success==True и Result==[whatever] или просто Success==False и Result==Nothing.

Кроме того, ваш вспомогательный класс MyParsableClassParsed может также использовать перечислитель вместо логического значения и / или список сообщений об ошибках, чтобы сообщить вызывающей стороне, как / почему произошел сбой операции анализа. Или исключение выброса может иметь такое перечисляемое значение и / или сообщение (я) об ошибке.

Намного проще и гибче в использовании. И все без ByRef, чтобы дать вам головные боли / предупреждения.