'out' issue in VB.NET

When in C# we have the out and ref parameter options, in VB there is a only one: ByRef.

Now, little 'problem' when trying to 'eliminate' the compiler warning saying that test was not initialized before passing as argument:

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

the class brief declaration:

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

maybe a solution was to declare

...Optional ByRef myParsableClass As MyParsableClass = Nothing)

but I can't set this parameter as optional one. What will happen if I'll miss it?

PS. (edit)

In the real project, my "parsable" class is MyHour with Hour and Minute properties. I wrote already the Parse(value as String) with a FormatException, but I think the code could be more clear, compact and quick when 开发者_运维问答I will not use try catch blocks...

I do not believe it's possible to prevent this warning, without an explicit assignment.

Different languages have different features/facilities - if they didn't, there'd only be one programming language :-) In this case, yes, VB doesn't pretend that there are two types of ref parameters, as C# does - so far as the CLR is concerned, "out" doesn't exist.

And I'm not sure what peSHIr is talking about - TryParse was added to later releases of the BCL for precisely the situation where a parse is as likely to fail as to succeed - so you can take a faulting path without requiring an exception to be thrown.

Edit

To add - the reason you don't get a warning for many of the built in types for which a TryParse exists (e.g. Int32) is because they're Structs/Value types, and hence always have a value. If your class is simple enough, would it be logical for it to be a Structure instead?

Not exactly an answer to your question, but out and ref/ByRef are bad, so why use them in the first place? Many developers think that the TryParse paradigm in the .NET Framework 1.0 was a bad way to go.

Why not go for a MyParsableClass that has a Public Shared Function Parse(ByVal value As String) As MyParsableClass method that raises an appropriate exception when needed?

Or even a Public Shared Function Parse(ByVal value As String) As MyParsableClassParsed where, MyParsableClassParsed is a helper inner class that contains two readonly properties: Success As Boolean and Result As MyParsableClass? You could then always get a result from calling Parse, but you'd get Success==True and Result==[whatever], or simply Success==False and Result==Nothing.

Also, your MyParsableClassParsed helper class could also use an enumerator instead of a boolean and/or a list of error messages to tell the caller how/why the parse operation failed. Or the throw exception might have such an enumerated value and/or error message(s).

Much easier to use and more flexible. And all without ByRef to give you headaches/warnings.